mobile frameworks

[Robert Gravina]

Hello from Tokyo!

I've been living under a rock as far as Rails and the surrounding
ecosystem has progressed over the last couple of years while I
maintained a Rails 2.3 app enviously looking on as everyone played
with all the new cool toys. Well, I still have to do that next year
but may get some time to develop some smartphone mobile applications,
or at least front-ends for some Rails app... probably nothing too
taxing, maybe audio/video playback but that's about it aside from your
usual tap-process-change the UI stuff.

So, just wondering if any of you esteemed ladies and gentlemen have
used any of the mobile frameworks out there, like Titanium etc., and
can recommend any of them? Do you use HTML/CSS/Javascript
cross-platform, or do you develop two apps in plain Objective-C and
Java? Or Ruby compiled to something that runs on the phone? Or some
other setup that I've never heard of due to living under the
aforementioned rock for so long?

Some or all of these features would be nice (assuming that you use one
of the cross-platform frameworks):

* Being able to target iPhone and Android without rewriting the whole
application.
* Ruby or JavaScript-based development.
* Open Source

I guess that's about it.

Thanks!

Robert

[Mike Bailey]

http://jquerymobile.com hit 1.0 in November. I've had a little play with it and was quite impressed.

I also found a great image gallery at http://www.photoswipe.com/

- Mike

Robert

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

--

- Mike

e. mi...@bailey.net.au

w. mike.bailey.net.au

[Simon Russell]

A bunch of games are done in Lua using various frameworks (which I'm
not really familiar with). And Titanium seemed impressive when I
tried it out (very superficially), and I've heard of people using it
successfully. I haven't seen anything convincing done with Ruby.

Depending on the app, however, the dream of cross-platform development
might be a little unattainable. Apart from the language differences
etc, just porting an app screen-for-screen from one platform to
another tends to be pretty obvious to the people using it. Users of
either platform tend to have incompatible expectations of how things
will work.

I'm by no means an expert though; I've mainly been involved in
building the backends for apps on both platforms, and have had pretty
close contact with the developers on both teams. That, and a fair bit
of reading. (And making a PhoneGap app on both platforms, but I
wouldn't recommend it except for the most trivial apps.)

I think the best non-game apps are written natively for both
platforms; if you're happy to make compromises, one of the frameworks
might be the right choice.

Simon.

[Aleksey Gureiev]

Not to spoil the party, Mike, but jquerymobile was very slow when we first checked (pre-release). I built a huge app with it and in the end we had to rewrite it from scratch with a custom framework so slow it was. Yes, bad choice on my part in the first place, but just sending smoke signals to everyone -- test it before you merry it, the divorce is going to be painful if you find it doesn't fit your expectations.

[Mike Bailey]

Oops, I thought Robert was asking about frameworks for mobile web apps.

I reckon http://soundcloud.com and http://twitter.com have produced mobile web apps that are as good as their mobile apps.

I'd be loathe of exclude Android or iPhone users but writing and maintaining two versions of an app just doesn't appeal to me. I recently decided I don't want to learn to write Android and iPhone native apps when mobile web apps have so much potential.

There are obviously applications for which a native app is going to be the best fit but I think mobile web apps are going to be the best choice a lot of the time.

- Mike

[Mike Bailey]

Thanks Alex, I should probably add that I haven't used jquery-mobile in anger.

Do you have any other recommendations for mobile web apps?

Can we have a play with your latest creation?

- Mike

On Wed, Dec 28, 2011 at 10:24 PM, Aleksey Gureiev <spyr...@gmail.com> wrote:

Not to spoil the party, Mike, but jquerymobile was very slow when we first checked (pre-release). I built a huge app with it and in the end we had to rewrite it from scratch with a custom framework so slow it was. Yes, bad choice on my part in the first place, but just sending smoke signals to everyone -- test it before you merry it, the divorce is going to be painful if you find it doesn't fit your expectations.

--

You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/nESq_P6t744J.

To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

[Fred Wu]

It largely depend on how you would like to structure your mobile app, and how much native control you need.

For instance, Titanium app is written in JS, but then the app gets compiled down to native Obj-C controls (unless you opt to use WebView, a.k.a the PhoneGap approach). Rhodes on the other hand, uses a client-server approach - you write your app in ruby, then your app runs on the Rhodes server via WebView.

As a web developer, the PhoneGap approach definitely is easier to transition to, and you would only write your app once, because everything is rendered in WebView. Titanium on the other hand, is more powerful because you get more native controls, but also you'd sometimes have to write two APIs - one for iOS and one for Android.

Now let's wait for Alan Harper to jump in and tell you why you should write native Obj-C/Java and not JS cross-platform. ;)

[Tim Uckun]

Nobody has mentioned Rhomobile http://rhomobile.com/. It's ruby and
rails like.

> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/rails-oceania/-/iPKVGdSX0bIJ.

[Aleksey Gureiev]

Hi Mike,

On Wednesday, December 28, 2011 1:33:13 PM UTC+2, Mike Bailey wrote:

Thanks Alex, I should probably add that I haven't used jquery-mobile in anger.

Do you have any other recommendations for mobile web apps?

Not really. The problem with all of them is that they *have* to be generic to be useful to the majority. We found that aside of the greater size, they tend to be slower as they attempt to formalize every aspect of the behavior through events and lots of handlers. Every app has its own requirements (some don't care about page change events, some don't need animation etc) and dragging everything just because it comes with the "box" isn't the best path given the limited CPU and memory resources.

We ended up writing our own framework that does exactly what we need and when we need for this reason. One of the devs I work with sketched the draft version literally over the weekend and then we polished it during the development. He used JS paired with native (hardware-accelerated) CSS3 animations for transitions. All this goodness is happily working inside the PhoneGap app on iOS and Android devices and *noticeably* faster than everything we tried before.

My advice would be to try jQueryMobile or anything else and sketch your app there much in the spirit of Lean Startup to quickly prove if your idea is viable, but keep everything as modular as possible to be able to replace the framework with something custom later on. Practice shows that anything more or less sophisticated hits the performance issues with its growth. Mobile platforms are so sweet, you never know when to stop adding those features. :)

Can we have a play with your latest creation?

Not at the moment, but the guys are about to launch the site and the apps pretty soon. Here's the link: http://appytravels.com/

 

Cheers,

A

[Julio Cesar Ody]

My 2 cents: use JavaScript (Backbone.js), HTML, and should you end up needing to go native for hardware access, say, use phonegap.

jQuery Mobile, while it does sort out a large array of issues related to mobile browsers incompatibilities, it's a lot slower than rolling your own, mostly around page transitions. So know what you're building and apply it accordingly.

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

[Andrew Harvey]

At Westfield we took the first option suggested by Julio. We hooked our rails app up to a backbone.js app on mobile devices. It's still fairly simple, but it does the job and looks native in parts. 

If you want to look in production: http://westfield.com.au/m

We'll be building on this over the next year. Hopefully we don't regret our choices. 

Andrew

Sent on the run. 

[Jonathan Clarke]

The page you are looking for might have been removed or had its name changed.

We went with the Sencha Touch + Phonegap option, worked well!

[Nicholas Faiz]

I'm interested to hear how others are approaching this problem, I have to do so next week! Phonegap looks interesting. If anyone has further suggestions please note them down here.

Cheers,

Nicholas

[Andrew Harvey]

How embarrassing...

http://www.westfield.com.au/au/m is the correct URL.

Sent on the run.

[Aleksey Gureiev]

Just to be clear. We did use PhoneGap to give our web app access to some native features (geolocation, background downloads etc), but also used our own JS framework to make the GUI look and feel nice and responsive.

- A

[Simon Russell]

We did a similar thing with PhoneGap (custom JS framework on top of
Zepto, some native feature integration) -- we got some pretty decent
performance on iOS, but trying to get it working across a bunch of
Android devices and OS versions wasn't particularly fun. We ended up
stripping out most of the UI gloss (transitions etc) -- which Android
phones are more than capable of, but not through the browser.

If you want to make a pretty basic app, PhoneGap might suit.

> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/rails-oceania/-/ncf4E3sutcoJ.

[Michael Pearson]

It's worth pointing out that the experiences with PhoneGap were negative enough to lead the company to hire a ten or so strong native iOS team :)

--
Michael Pearson

[Samuel Richardson]

This is all quite terrifying, I recently played around with PhoneGap before I went on holiday and recommended it for an upcoming project that's happening in the new year. After reading this feedback I'm beginning to get second thoughts.

My approach was going to be PhoneGap coupled with jQuery Mobile or jQTouch/Zepto. The app itself is not very complicated, just a directory of people coupled with a search. The database would be stored locally and I was planning on transferring a delta of changes over every time their is an update.

Has anybody used the new jQueryMobile 1.0? It's promised to be quite a bit faster. Reading about people having to disable page transitions etc for Android phones is making me quite uneasy about what I thought was a pretty straightforward thing ;)

Samuel Richardson
www.richardson.co.nz | 0405 472 748

[Simon Russell]

I might not be a disaster -- that sounds like the sort of thing
PhoneGap does okay. The app we did that wasn't so great was heavy on
graphics, and probably could have been done a lot more simply if it
had been planned to take into account the limitations from the start.

On the upside, a bit of quick fiddling around with a static HTML + JS
+ CSS mockup, using the internal browser, can teach you quite a lot
about what's possible on the phone. Adding the right meta headers for
the iPhone that remove the address bar etc can basically give you the
full app experience, without the hassle of building the full phonegap
thing -- good for development, and initial demos.

[Chris]

This is an excellent discussion!

Pretty soon, I too will be embarking on creating a mobile interface for some of our web apps.

The impression I get from the sounds of things is that, ultimately, any framework you choose is a sideshow to the core concerns of mobile interfaces: pared down, snappy and responsive.

The recurring theme seems to be either a custom glue framework, backbone or a hybrid of the two. It makes sense; most of the data you'll be piping down to the client is gonna be via JSON, so something to formalize the access and manipulation of that is the key consideration. Everything else is gravy; a mere convenience to aid building something a little flashier.

I'll likely be following that rough guide -- almost all the data should be accessible via JSON at a REST endpoint. Coupled with Sinatra or something else to throw some data around, that should allow for spiking a few approaches to building the UI layer without getting too tied down to any one approach.

Sent from my iPhone

[Aleksey Gureiev]

I wouldn't be so categorical. PhoneGap is not a cure to everything, but it works fine. I wrote several plugins and fixed several issues with the core along the way. It does a great job of exposing native features to JS. That's basically all to it, so it's not to blame if you have poor performance. If you need geo / native alerts / access to database and files / etc, you go with PhoneGap (or any other similar libraries) + JS framework, if not -- you go with whatever JS framework you choose only (or write your own).

- A

[Dmytrii Nagirniak]

I remember I was at one of the YOW talks last year (haa last year, can you believe that!) where REA guys talked about their iPad, iPhone and Android development.

The most important takeaway they tried to deliver is that one should avoid using "cross-platform" frameworks as much as possible.

I haven't done any mobile development, but I tend to believe them :)

Cheers,

Dmytrii

On 31/12/2011, at 10:50 PM, Aleksey Gureiev wrote:

I wouldn't be so categorical. PhoneGap is not a cure to everything, but it works fine. I wrote several plugins and fixed several issues with the core along the way. It does a great job of exposing native features to JS. That's basically all to it, so it's not to blame if you have poor performance. If you need geo / native alerts / access to database and files / etc, you go with PhoneGap (or any other similar libraries) + JS framework, if not -- you go with whatever JS framework you choose only (or write your own).

- A

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/nmBqYXfJ74sJ.

[Tim Uckun]

>
> The most important takeaway they tried to deliver is that one should avoid
> using "cross-platform" frameworks as much as possible.
> I haven't done any mobile development, but I tend to believe them :)

The alternatives seem to be worse though. You either ignore half the
market or you write your app twice.

[Michael Pearson]

I think the cross-platform alternative is that you write an app that nobody uses.

-- 

Michael Pearson

[Chris]

That's my thought as well. 

If you're worried about being cross-platform before you've built it, you're consigning yourself to taking longer to build it and against more moving targets, which reduces your ability to focus. Specifically, you have less opportunity to focus on just building value in to your app.

[Aleksey Gureiev]

Writing cross-platform isn't *that* hard, if you have someone on the team who did this at least once. There are certain things to avoid and know, and that's about all to it. Unless you go deep into old devices, you are safe with HTML5 / CSS3. Most modern Android and iOS gadgets (those on Webkit) support these and even w/ accelerated transitions / animations. If you stay within what's supported, that's all you need for successful cross-platform development. Once you need something native (positioning, integration with apps etc), here's where PhoneGap or alike come into play.

One excellent resource you can consult: http://caniuse.com/

- A

[Julio Cesar Ody]

You're probably aware, but for those who aren't, the fact it's listed
as supported on caniuse.com isn't enough. I think I mentioned that on
my WDS presentation: when you get down to actually running an app on
*many* Android devices, you'll often see stuff such as dog slow CSS
transitions, and weird behaviour for *a lot* of CSS3 (off the top of
my head, fixed positioning being one of the worst) despite support
being technically there.

Also, mobile Android isn't a single platform. It's as many as there
are versions of Android. And each is a moving target as time goes by.

The question, IMHO, for as long as the status quo remains, is: what's
my target audience. Then you go and develop for it. Your mileage may
vary along with the project's budget.

> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/rails-oceania/-/Ac1Xs_LgpaMJ.

[Dmytrii Nagirniak]

On 04/01/2012, at 12:02 AM, Aleksey Gureiev wrote:

> There are certain things to avoid and know, and that's about all to it. Unless you go deep into old devices, you are safe with HTML5 / CSS3.

That's exactly the opposite what REA guys were talking about.
As far as I remember, there are huge differences between iOS and Android devices. Not only technical, but also UI/UX, how interactions work, the reaction to different buttons (iOS devices have basically 1 hardware button, Androids have multiple which are often inconsistent, don't even know about BB and others).

The point was that you can't make it seamless/native on all devices because those are just way too different from many perspectives.

But if one doesn't care about it, then probably a framework is a good choice.

Cheers.

[Simon Russell]

Indeed, we experienced the multiple-Android problem quite frequently
when using PhoneGap. Even within the same version of Android, on
different models there are strange differences, and the TouchWiz etc
"enhancements" sometimes interfere (keyboards, for example). Android
native apps have a pretty decent approach to targeting multiple screen
sizes etc; you don't have access to that when you're doing a PhoneGap
app. So you end up spending a lot of time testing and fixing bugs on
each handset. So the "quick win" of easy cross platform development
becomes a massive weight on your shoulders down the track.

Unless you keep it ridiculously simple, or you're only targeting the
iPhone. Even then you won't get around the strange delays on pressing
buttons, and the general feel that it isn't quite a native app. And
if you're only targeting the iPhone, why not crack out the ObjC?

[Caroline Gordon]

Hey,
any update to this? I notice Westfield now have an app in the Android
app store, did you go native for that or use PhoneGap or something?

Caroline

On Dec 29 2011, 11:21 am, Andrew Harvey <synap...@gmail.com> wrote:
> How embarrassing...
>
> http://www.westfield.com.au/au/mis the correct URL.
>
> Sent on the run.

>
> On 29/12/2011, at 9:29, Jonathan Clarke <jonat...@beilabs.com> wrote:
>
>
>
>
>
>
>
> > The page you are looking for might have been removed or had its name changed.
>
> > We went with the Sencha Touch + Phonegap option, worked well!

> > On Thu, Dec 29, 2011 at 8:44 AM, Andrew Harvey <synap...@gmail.com> wrote:
> >> At Westfield we took the first option suggested by Julio. We hooked our
> >> rails app up to a backbone.js app on mobile devices. It's still fairly
> >> simple, but it does the job and looks native in parts.
>
> >> If you want to look in production:http://westfield.com.au/m
>
> >> We'll be building on this over the next year. Hopefully we don't regret our
> >> choices.
>
> >> Andrew
>
> >> Sent on the run.
>

> >> On 29/12/2011, at 4:48, Julio Cesar Ody <julio...@gmail.com> wrote:
>
> >> My 2 cents: use JavaScript (Backbone.js), HTML, and should you end up
> >> needing to go native for hardware access, say, use phonegap.
>
> >> jQuery Mobile, while it does sort out a large array of issues related to
> >> mobile browsers incompatibilities, it's a lot slower than rolling your own,
> >> mostly around page transitions. So know what you're building and apply it
> >> accordingly.
>

> >> On Wednesday, December 28, 2011, Robert Gravina <robert.grav...@gmail.com>

[Bayan Khalili]

Hi,

Warning: shameless plug ahead ;)

For those interested in seeing a jQueryMobile web app in production, you're welcome to take a peek at the mobile interface for our hotel booking engine:

http://m.thebookingbutton.com.au/demo

Please let me know if you have any questions related to my opinions or experiences with this framework. Otherwise, I'll step back into the shadows and put this thread back to rest...

Regards,

Bayan

[Robert Gravina]

On 2 March 2012 06:20, Bayan Khalili <baya...@gmail.com> wrote:
> Please let me know if you have any questions related to my opinions or
> experiences with this framework. Otherwise, I'll step back into the shadows
> and put this thread back to rest...

Before you do, I'd just like to thank everyone for their great
responses. While I didn't comment at all during the thread, I did read
everything :)

The mobile dev work hasn't started yet but when it does, I'll dig this
thread back up.

Cheers!

Robert

[Jason Kotchoff]

Has anyone out there given RubyMotion a whirl yet?

It's in-built testing and inspection frameworks look really cool..

Here at ProjectProject, we built a bunch of apps in PhoneGap over the past two years but have recently migrated over to Appcelerator Titanium (I think Aleksey mentioned this earlier in the thread).

Our experience has been:
PRO:  Both of these JavaScript based frameworks were useful in enabling some of less technical graphics guys to modify apps without the overhead of learning Objective C

PRO: Titanium allows you to get up and running super-quick and has a pretty well documented API

CON: PhoneGap can perform perceivably slower then a native app given the WebKit overhead

CON: Phonegaps CSS and window management can be really obscure and finicky and sometimes leads to weird 'screen placement' bugs

CON: Apparently porting a complicated Titanium app to Android required a lot of work (aleksey?)

Right now, we are building all our new projects in Titanium but this RubyMotion definitely looks interesting.. Thoughts?

[Fabio Vilela]

I built an app using jquery mobile and phonegap... It is good to develop the interface and controllers without having to run on a simulator, but once on the phone, I thought it was really slow. A bit frustrating to be honest. I was blown away by the rubyMotion video. I will give it a go as soon as one of you guys in the list write a scaffold for it hehehe. 

Fabio.

--

You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/uRHKmcG9MlMJ.

[Ben Taylor]

I'm currently using RubyMotion to build a little Umbrella Advisor app. I've also done a bunch of random fiddling around with it and have quite enjoyed it. Previously I've used PhoneGap and found it super frustrating. As soon as I needed to anything they hadn't specifically implemented for me I had to drop back to Objective C and implement it, as well as a bridge to JS. It got much too complex much too quick.

The difference here is that your Ruby code is being compiled and run within the Objective C environment. All of the standard Ruby library also sits on stop of Cocoa. Plus you can do neat things like Reopen a Objective C class and monkey patch your own methods in there. Here's a little tweet of mine that did the rounds a while ago https://twitter.com/taybenlor/status/217082997516673024

The biggest downside is that you can't use the Xcode UI and Core Data tools. However on the other hand, you don't have to use Xcode. So I see it as a bonus :P

If you do end up doing some RubyMotion, check out the community projects here http://github.com/rubymotion some of them are really useful.

As for the Umbrella app, the site or app isn't live yet but, as a preview: 

http://cl.ly/0B3v2Q141Y4547192x2Y

 - Ben

--

[Andrew Stone]

I saw a demo at a user group a month or so ago... looks pretty neat, but afaik it only targets iOS? which is a bit of a shortfall given most of the other like toolkits at least target both android and iOS?

Stonie.

--

[Ben Taylor]

There's two good reasons why it only targets iOS:

  * It's based off the MacRuby project (OSX Apps written in Ruby)

  * You directly call CocoaTouch methods so there's no possibility of code sharing

Theres also a huge difference in performance between the JavaScript based options and RubyMotion, due to it's compiled nature and lack of wrapper libraries.

From my experience trying to develop cross platform with PhoneGap, beyond the trivial, you're going to have to do a lot of special casing - to the point where it's probably worth having a dedicated code base for each platform.

I don't know enough about Dalvik, but perhaps it would be possible for someone to do something similar with JRuby and Android libraries. Then you could at least have the one language (Ruby) for both platforms. In fact, a cursory google has brought up http://ruboto.org/

 - Ben

[Tate Johnson]

On 06/07/2012, at 10:34 AM, Ben Taylor wrote:

> I'm currently using RubyMotion to build a little Umbrella Advisor app. I've also done a bunch of random fiddling around with it and have quite enjoyed it. Previously I've used PhoneGap and found it super frustrating. As soon as I needed to anything they hadn't specifically implemented for me I had to drop back to Objective C and implement it, as well as a bridge to JS. It got much too complex much too quick.

I had a similar experience using PhoneGap at the start of the year. The tools are getting better (Remote Web Inspector in Safari 6), but do you really want to bring the baggage of the web on to your mobile? I like laying out a view and knowing it's going to look exactly like that. I spent a tonne of time dealing with things that stopped me from writing real code.

> The difference here is that your Ruby code is being compiled and run within the Objective C environment. All of the standard Ruby library also sits on stop of Cocoa. Plus you can do neat things like Reopen a Objective C class and monkey patch your own methods in there. Here's a little tweet of mine that did the rounds a while ago https://twitter.com/taybenlor/status/217082997516673024
>
> The biggest downside is that you can't use the Xcode UI and Core Data tools. However on the other hand, you don't have to use Xcode. So I see it as a bonus :P

You can definitely use storyboarding with RubyMotion. It's more awkward because you cannot plug actions and outlets, but with minimal glue I think it's an acceptable trade off. I gave a talk last month at the Brisbane Ruby and Rails Brigade demonstrating this technique. The code and screenshots are available at https://github.com/tatey/posts.

On the other hand, I think we're going to continue to see an explosion of DSLs for taking the pain out of rolling your own views anyway. I'm interested in watching this space.

Cheers,
Tate

[Fred Wu]

FYI for those of you who are interested in RubyMotion, the latest Change Log episode has Laurent Sansonett - the man behind MacRuby and RubyMotion as a guest:

http://thechangelog.com/post/25928209107/episode-0-8-2-ruby-motion-macruby-and-more-with-laurent