The Shape of Mobile Development To Come • Hacker News Board

Re: The Shape of Mobile Development To Come

#31

Post by cageface » Mon, Jul 30, 2012, 3:51 AM UTC

stcredzero wrote: post #24

jiggy2011 wrote: post #14

The problem with write once run anywhere is that it's not desirable to device manufacturers apart from those on the bottom rungs who don't have a big enough developer community to carry the devices on their own. If MS and Apple threw JVMs onto their devices then we would be 90% of the way there already. If any write-once-run-anywhere solution becomes to popular then the likes of MS or Apple will try their best to kil…

> If MS and Apple threw JVMs onto their devices then we would be 90% of the way there already. As a one-time proponent of write-once-run-anywhere solutions, I would have to say this would probably result in a reduction of UX quality.

I think the MonoTouch guys are handling this in the only sensible way. Non-UI code is shared across platforms but UI code is written per-platform using the native toolkit. I think this is about as close as you're going to get without compromising user experience.

Re: The Shape of Mobile Development To Come

#32

Post by kennywinker » Mon, Jul 30, 2012, 3:55 AM UTC

QuickDialog (http://escoz.com/open-source/quickdialog).

Showing a dialog:

    NSDictionary *dataDict = @{'title':'example', 'other':'other text'};
    QRootElement *root = [[QRootElement alloc] initWithJSONFile:@"file" andData:dataDict];
    QuickDialogController *myDialogController = [QuickDialogController controllerForRoot:root];
    [self presentModalViewController:navigation animated:YES];

example json form definition file to match:

    {
        "grouped": true,
        "title": "Example QuickDialog Form",
        "controllerName": "QuickDialogController",
        "sections": [
        {
            "elements": [
                {
                    "type": "QEntryElement",
                    "title": "Title",
                    "placeholder": "item title",
                    "bind": "textValue:title"  },
                {   "type": "QMultilineElement",
                    "title": "Other info",
                    "bind": "textValue:other" }
                ]
            }
        ]
    }

data from dataDict is merged into the fields defined in the json definition file, using the bindings specified in the 'bind' property.

It's really awesome, and makes all kinds of dynamic views possible. I was skeptical at first (as I am about most cocoa libraries) but I'm pretty sold on it since I gave it a fair shot.

Re: The Shape of Mobile Development To Come

#33

Post by spaghetti » Mon, Jul 30, 2012, 4:14 AM UTC

The article's mention of beautifully designed mobile apps sparked a few thoughts for me. One property of mobile devices and especially smaller devices like phones is people use them frequently throughout the day in short bursts. Small wait times associated with bouncing, translating animations etc are magnified and the UIs start to feel laggy. Yesterday I purchased my first Android device and the snappy UI has been quite a nice change. This is a relatively low-end Android device. And I've been using an iPhone 4S for the past few months.

So I think the design of mobile apps will be simplified going forward. I could see moving towards simpler UIs like Craigslist. This is a major win in a variety of ways: faster UIs implies better user-experience, less computationally intensive UIs implies less drain on limited resources, and simpler UIs implies less design and development time. I love the idea of never stressing out about rounded corners, little shadow and shine marks etc. They're nice to have initially but just get old as one uses the same device/OS/apps for months on end.

Re: The Shape of Mobile Development To Come

#34

Post by skybrian » Mon, Jul 30, 2012, 4:26 AM UTC

The notion that business logic doesn't belong in the client is wrong because you need it when working offline. And sharing UI code is a pipe dream if you want native look and feel. (If you have a custom UI anyway like in a game, it's more feasible.) A more realistic goal is port the business logic, networking code, storage, and so on, and rewrite the UI code for each platform.

Re: The Shape of Mobile Development To Come

#35

Post by 10char » Mon, Jul 30, 2012, 5:08 AM UTC

kennywinker wrote: post #32

QuickDialog ( http://escoz.com/open-source/quickdialog ). Showing a dialog: NSDictionary *dataDict = @{'title':'example', 'other':'other text'}; QRootElement *root = [[QRootElement alloc] initWithJSONFile:@"file" andData:dataDict]; QuickDialogController *myDialogController = [QuickDialogController controllerForRoot:root]; [self presentModalViewController:navigation animated:YES]; example json form definition file to…

Ha, I actually wrote something really similar (without knowing about QD) for RubyMotion: https://github.com/clayallsopp/formotion

Ruby is better suited to this IMO (no clunky file loading), but I agree they both prove dynamic native views need more exploration

Re: The Shape of Mobile Development To Come

#36

Post by kennywinker » Mon, Jul 30, 2012, 5:25 AM UTC

10char wrote: post #35

kennywinker wrote: post #32

QuickDialog ( http://escoz.com/open-source/quickdialog ). Showing a dialog: NSDictionary *dataDict = @{'title':'example', 'other':'other text'}; QRootElement *root = [[QRootElement alloc] initWithJSONFile:@"file" andData:dataDict]; QuickDialogController *myDialogController = [QuickDialogController controllerForRoot:root]; [self presentModalViewController:navigation animated:YES]; example json form definition file to…

Ha, I actually wrote something really similar (without knowing about QD) for RubyMotion: https://github.com/clayallsopp/formotion Ruby is better suited to this IMO (no clunky file loading), but I agree they both prove dynamic native views need more exploration

That looks remarkably similar. Were you also influenced by MonoTouch.Dialog, as was QuickDialog's developer?

Re: The Shape of Mobile Development To Come

#37

Post by 10char » Mon, Jul 30, 2012, 5:33 AM UTC

kennywinker wrote: post #36

10char wrote: post #35

Earlier quoted context omitted.

Ha, I actually wrote something really similar (without knowing about QD) for RubyMotion: https://github.com/clayallsopp/formotion Ruby is better suited to this IMO (no clunky file loading), but I agree they both prove dynamic native views need more exploration

That looks remarkably similar. Were you also influenced by MonoTouch.Dialog, as was QuickDialog's developer?

Nope, developed it totally independently according to my needs.

Re: The Shape of Mobile Development To Come

#38

Post by tomjen3 » Mon, Jul 30, 2012, 6:12 AM UTC

sandofsky wrote: post #15

rmason wrote: post #13

Earlier quoted context omitted.

I remember well the assembly language crowd making the same argument back in the eighties. Processors got faster and machines shipped with more RAM. The tipping point was reached and all of a sudden no one was writing entire programs that way.

While you wait for the tipping point, I'll be over here shipping.

That is fine. We will eat your lunch on version two.

Then hire you on a great salary because great programmers are hard to find.

Re: The Shape of Mobile Development To Come

#39

Post by troymc » Mon, Jul 30, 2012, 6:30 AM UTC

I did some research into the currently-available toolkits that let you write one code base to create mobile apps for iOS, Android, and (maybe) other mobile operating systems. I was astounded by how many options are currently available: more than 50! I made a website to summarize my findings; see http://www.mobilechameleon.com/

Re: The Shape of Mobile Development To Come

#40

Post by rimantas » Mon, Jul 30, 2012, 6:58 AM UTC

10char wrote: post #6

ecspike wrote: post #3

He lost me with his "Objective-C ...has evolved over the past two years to become an "easier" language ... " I would argue that it has less to do with the ease of the language and instead the market effects of iOS.

I think you might've misinterpreted what I meant? I didn't mean to imply anything about the growth of iOS or that ObjC being just perceived as an easier language because of the growth. I trying to say that Objective-C was really criticized for its verbosity and forcing manual memory management, and Apple has made changes in direct response to those with ARC and more concise literals, which IMO makes it "easier" (espc…

Also @property — first you had to declare variables and use @synthesize, then you could omit the declaration part, and no you can omit the declaration and @synthesize, @property alone is enough.