I've just spent a lot of time looking into the best ways to create iphone and android apps for an existing rails app that I've built and I feel that I haven't actually gotten any closer to knowing how to best achieve this.
What I want:
I would like to have the rails app and the mobile code cleanly separated. I'm not looking to just render a different layout in my rails app. I'd prefer to use something like phone gap that allows me to use roughly the same codebase to run the mobile apps.
I'd like to have offline/sync capabilities in the mobile apps (hence if a user creates a record on their iphone while they are out of coverage the app should save the record on the phone and continue to try to to sync that record to the web app until success.
Having access to the hardware features will be needed down the road. GPS, accelerometer, etc.
My questions:
Is this a good situation to use oauth? Would I just build an oauth provider into my web app and then build the two mobile apps as clients to the web app?
Is there an easier method for secure authorization that I'm missing?
Does Devise work with oauth? My app is built on top of devise at the moment.
Is this syncing something that should be abstracted to a middleware or metal?
Sorry, I know this is actually a lot of questions but I'd like someone who is familiar with the situation to answer in a comprehensive manner rather than just a couple little pokes that leave more questions. I feel like this has to be a common situation now-a-days but I can't seem to find anything up-to-date in my searches.
Cheers!
ps. - If you've done something like this yourself and know how to pull it off, I'd love to talk to you directly. I'll even buy the beers. Seriously... no takers?
I am building a mobile application with a grails backend, must support android and iphone
I have done a few iterations so far while attempting to settle on technology, a native objective-c, native android, phoneGap and titanium appcelerator.
for authentication I use HTTPS with basic auth. I know people are concerned about basic-authentication, but it has been argued both ways see this StackOverflow Question
I have not solved the syncing problem yet, but I dont expect to implement that complex of a solution initially, will store local content (XML or JSON) and push back to server on demand. Content is stored locally in same format used when posting to server
Backend in grails, all REST API calls are logged and authenticated on each request. Will probably add additional security only allowing specific registered devices to access the API as and additional level of security
I've been building a iPhone app with a Rails back end. I've been using Objective-C because it needs the full Core Location framework which isn't available with a browser based solution. So if you want to use the full capabilities of the device, you have to use the native development environment.
I've been using Objective Resource http://iphoneonrails.com/ which is an open source framework that provides Active Resource-like extensions to Objective C NSObject classes and plays very well with my Rails App. You just have to put in render JSON or XML for your controller actions like in the example below.
class UsersController < ApplicationController
# GET /users
# GET /users.xml
def index
#users = User.all
respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => #users }
format.json { render :json => #users }
end
end
I don't if this answers all your questions as I don't know enough about your app but it's a good starting point.
Maybe you will find useful my example rails + ember.js App with token authentication based on ember-auth and several OAuth strategies. It is responsive and works both as a desktop and mobile App with Phonegap.
Currently in de the devel branch: https://github.com/joscas/base_app/tree/devel
Life here: https://starter-app-staging.herokuapp.com for the desktop version.
It uses the phonegap-rails gem (of which I'm also the author) to export the apps assets, fix paths etc without hassle.
Related
I have an ASP.NET (not MVC) application.
I would like to create a version that is optimised for browsers on the IPhone and on Android.
Some questions
Is it possible to detect IPhone/Android when the site is accessed
Are there any gotchas/tips for developing ASP.NET for these devices.
We're using a combination of .net webforms and jQuery mobile.
For our viewstate, it's been pretty well neutered already so only minor stuff is going down to the device.
Bear in mind that there are around 3 different mobile api's. Each of which has their own drawbacks. You might want to investigate each.
Also, we took the approach that the mobile site was a completely different website than our standard one. When the user comes in, we do some browser sniffing and push them to mobile if it matches with a link to move back to the full one if they want.
Webforms aren´t good for mobile, it generates big pages because viewstate. And you can´t control rendering (some more in .net4).
You can detect device using a db of capabilities like WURFL (I recommend 51degrees) o maybe using some like http://detectmobilebrowser.com/
I don´t know what kind of webapp but you could make a new app, maybe using MVC. Please look this resource.
I searched arround for solutions and didn't find anything of really pertinent on the subject.
This is why, I ask you guys your help :-)
Assuming I have an application running with Rails 3 using Devise to authenticate the users.
I need to create mobile applications for Iphone/Android and WP7.
The mobiles applications should communicate/login/create/list, do whatever the website can do.
The mobile Applications could commuicate by parsing the XML .... but maybe there are already lib/frameworks or something more sexy ?
What would be the best way to communicate between my mobile applications and my Rails website ?
I'd use the xml or json output to share data back and forth; For authentication you can set (in initializers/devise.rb)
config.http_authenticatable = true
That enables you to send basic HTTP Auth headers with every request which devise will handle for you.
--
For creating a webapplication that is also possible to view in a mobile version for the website i'd recommend to check out this railscast: http://railscasts.com/episodes/199-mobile-devices
It sounds like, if the mobile app is just an interface to the web app, that you would likely be best served by creating a mobile HTML5 "style" within your web app, that gets served automatically when a mobile phone accesses your website. All of your code can be in Rails, which it sounds like you're already familiar with, and you've also got the advantage of keeping your codebase all together in one place - if you want to add functionality later, you just update your web app, and don't worry about updating 2 different mobile phone apps as well.
I need to create an app for a large company.
Their aim is to distribute this app to all of their customers (who themselves are companies - not individuals) and the end-user will be able to query their relevant information through this app.
The app will receive all of its data through webservices and will require login on every use.
On the one hand a web application might be suitable as all the data is anyway online and also distribution of such an app would be trivial.
On the other hand, they might want features in the long term which use the camera etc. and also the administration of the website (in addition to the existing web services) might be a problem - which means a native app working with web services is the solution.
The next question is the preferred way of distribution for this app if it is a native app.
I know Apple have the Enterprise program (which seems to have changed - I no longer see the reference to >500 employees or 250 device limit).
In my case there is one main company distributing the app to many customers so I don't know whether this program is appropriate.
Any advice would be appreciated.
I once had a similar problem... we ended up with the application in the store and an authentication mechanism inside the application. Most likely, customers would have to provide the user credential they use to authenticate at the web application to the iPhone app as well.
For the decision whether to build a native application or use a web application, I would recommend using a hybrid approach. This way you can start with an application which is based on an UIWebView and extend it with features only available to native applications...
I'm about to begin development of an iPhone app. The app itself is fairly basic, and I want a speedy turnaround time.
I'm a web developer myself, specialising in traditional web technologies such as PHP/MySQL; I have no experience in Objective-C.
My plan was to create a very basic iPhone app that is just a Safari service that passes some basic variables to a URL. That URL is the app built in PHP and housed on my servers, this way I can create the app very quickly without needing to outsource anything.
My question is whether apps of this nature would be accepted into the iTunes store, or would they be out-right rejected? Anyone's experiences or comments are very welcome.
Thanks
It could go either way, but mind bullet 12.3 from the App Store Review Guidelines:
12.3 Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected
In my opinion, a simple UIWebView wrapper around your web site comes close to the definition of a simple web clipping. Your approval may very well hinge on your luck in drawing a sympathetic reviewer.
It really depends upon your application...These kinds of application have been approved in the past but again I am saying that it depends on many factors.
Try to test your app in every possible manner and also keep in mind the memory issues.
Best of luck!!!
Should be fine - its called a web app and there is software out there that will do just this for you.
All you need to do is to make a UIWebView and put your web app into it.
Also look at http://jqtouch.com. That gives you some idea of what you can do web-side. :)
http://www.netbiscuits.com/559
Native Hybrid Apps
Native apps can interface more deeply
with the mobile handset modules and
sensors to create an even richer
mobile user experience. Netbiscuits
provides pre-build native apps
frameworks for all major mobile
operating systems to be easily
customized for the needs of
enterprises.
Get "2in1" by combining the power of
mobile websites and native apps by
wrapping mobile websites into hybrid
apps and list them easily in all major
app stores of providers like Apple,
Nokia, Google or Samsung to open a new
mobile distribution channel. The
benefits of this approach are fast
time to market, minimized development
and maintenance efforts and maximum
mobile cross-platform technology
coverage.
Yes, it will be accepted as long as you stick with HTML, CSS, JS and Obj-C on the client side. You still need to wrap it in an iPhone app. In my experience, the best way to this is to use http://www.phonegap.com/ or a similar framework.
You'll have the option of deploying you app through iTunes or as a regular web app (you users will be able to create a link to your web app right on their springboards)
It SHOULD be accepted, granted you test test test and make it look just like a native application. Also you'll have to make sure that your server is never down, or if the application can't reach it just display an error message. You also have to keep in mind that there are a lot of iPod Touch users, and they don't have access to the internet all the time. Which means that chances are you'll get a BUNCH of 1 star reviews
I think about starting from scratch building a small application fullfilling two technical requirements:
should be usable on iPhone
should work offline
There are two obvious alternatives here to choose between
A real iPhone application with offline capabilities
A web app using HTML5 offline, Google Gears or similar
Having no iPhone app development experience (I don't own an iPhone), i wonder which way would be the easiest to go?
What are the learning curves for building offline HTML vs building an iPhone app?
Honestly, it depends what your app is going to do.
MobileSafari supports all the HTML5 offline stuff, so you could store data in a clientside SQL database, cache the application clientside, etc... The mobile Gmail app is probably the most notable example of that, giving you full-featured access to your Gmail even when offline. You can also use geolocation through JavaScript APIs that were added in 3.0. Web Clips let your web app share the home screen with native applications too. There is more on using web apps on the iPhone on this Stack Overflow post.
Obviously, doing a Web app will be of interest to people who like dealing with HTML, CSS, and JavaScript (and possibly whatever language is running server-side). It is possible to do really neat stuff with offline Web apps, but its performance won't be as good as that of native apps, especially on pre-3GS devices.
Developing a native application will require you to learn Objective-C (or C# as soon as Mono Touch is available to the masses) and pay a $99 fee to be allowed to test on-device and deploy to App Store. A lot more of the system is exposed to you through the various APIs, such as the camera, compass, multitouch, and so on.
Objective-C is pretty simple to pick up if you're familiar with Java; you only really need to get used to the square bracket syntax and memory management and then it's pretty straight-forward.
Then there are the hybrid systems, like PhoneGap, which expose more of the device's APIs, provided the Web app runs in a special container app. It is also crossplatform, so you could also deploy the app on Android and BlackBerry if you wanted to. This still requires you to pay the App Store fee, but if you're more familiar with Web development, this gives you the best of both worlds.
I can't tell you too much about HTML apps in general, but I can tell you that the API for the UIWebView is extremely minimal, and of course there is much less you can do than in a native iPhone application.
An HTML5 offline app would have security issues as you would have to hard code your oauth secret into code that anyone could see ( by clicking view source, or inspecting in Firebug ). You could simply use http auth, but then you get the ugly "from API" credit with every tweet sent from your app, and also that ugly http auth popup from the browser.