Hey guys,
I am about to develop my first mobile app with the same function of a
website I have developed in rails. So I have a few questions:
-
My plan is to create an API to the website and build the app using
that
API to my website. In your experience is that a good solution?
-
Whats the best option, use a cross-platform framework like
http://rhomobile.com/ ? something like rubymotion for iOS and try to
find
another framework for android? or actually just do it on the given SDK?
-
Should I not even worry about developing a website and go straight
ahead
with the app leaving the API idea behind?
-
Any other suggestions?
all the best,
Andre
On 24 August 2014 17:08, [email protected] wrote:
Hey guys,
I am about to develop my first mobile app with the same function of a
website I have developed in rails. So I have a few questions:
- My plan is to create an API to the website and build the app using that
API to my website. In your experience is that a good solution?
Yes, but you should not need a separate API, you can use the same
routes but with .json to return a json value for the app.
- Whats the best option, use a cross-platform framework like
http://rhomobile.com/ ? something like rubymotion for iOS and try to find
another framework for android? or actually just do it on the given SDK?
Don’t know about cross platform support, I have only done android, using
the SDK
- Should I not even worry about developing a website and go straight ahead
with the app leaving the API idea behind?
I thought you said you already have developed the website so I don’t
understand the question.
- Any other suggestions?
There is an alternative that may be a quick route to getting something
working, which is to embed the website in an app. It will not give as
good a user experience as an fully fledged app of course.
Colin
2014-08-24 18:32 GMT+02:00 Colin L. [email protected]:
Yes, but you should not need a separate API, you can use the same
routes but with .json to return a json value for the app.
Yea thats true and makes totally sense. Thanks
- Whats the best option, use a cross-platform framework like
http://rhomobile.com/ ? something like rubymotion for iOS and try to
find
another framework for android? or actually just do it on the given SDK?
Don’t know about cross platform support, I have only done android, using
the SDK
- Should I not even worry about developing a website and go straight
ahead
with the app leaving the API idea behind?
I thought you said you already have developed the website so I don’t
understand the question.
Well It’s more like a question for the future. If I need a app to
start
with, is it a good practice to still do the website and use the common
API
or to just develop the app?
On Aug 25, 2014, at 8:42 AM, Andr O. [email protected] wrote:
Well It’s more like a question for the future. If I need a app to start with, is
it a good practice to still do the website and use the common API or to just
develop the app?
It depends on your market. The advantage of the web site is that it runs
on anything, Linux/*BSD, ChromeBooks, Windows, OS X.
–
Scott R.
[email protected]
http://www.elevated-dev.com/
(303) 722-0567 voice
We have had good success with PhoneGap (also known as Cordova). However,
you will need to write a client app that is written in a framework like
Backbone, Angular, Ember. I don’t know much about RHOMobile but maybe it
is a competitor to PhoneGap/Cordova?
As far as back-end, I actually do recommend you create a versioned API
that operates at distinct route from your main web-based app. There are
good reasons to do this – specifically, a versioned API will operate at
a url like /api/v1/. This will mean that in the future if you want to
change the output of the API, you can do so by creating a new API
version number (/api/v2) and still have your old mobile clients use the
old API (which you generally leave-in-place to support older clients
rather than replace)
Another good reason to create a versioned API instead of using existing
Rails endpoints is that it actually forces you to move your domain logic
out of your controllers. You controllers-- both your Rails controller
and the API controllers – should be really, really lean and never
contain any domain logic (business logic). If you have a lot of IF
statements in your controllers, you probably have too much domain logic
in the controllers. Writing more controllers, although it does have an
added cost of more controllers to maintain, actually can help you
abstract the domain logic into context objects or model objects where
they belong. This is because if you have two controllers with repeated
code in them it becomes very obvious that that repeated code is domain
logic and should be encapsulated into either a model, service object, or
DCI object. Doing it this way is a little more work but in the long run
you end up with better product.
Also, ActiveModel serializers
(GitHub - rails-api/active_model_serializers: ActiveModel::Serializer implementation and Rails hooks) have come a long
way in the last year or so, and now do some really fancy stuff like root
element control, arrays, embedded associations, and side-loading data.
If you aren’t familiar with what these are, learn them before getting
started as they will affect the architecture of your API.
-Jason
Hey guys,
Thanks for your input. I have done API’s before in rails and I
understand
and follow the advices on using a versioned API. I think what Collin was
trying to say is in the beginning to get the app development going I
should
be using the common API, and after build a version API.
I also agree on using the domain/model objects and more controllers as
that
helps to modularize code.
My biggest doubts maintain on which technologies should I use to build
my
app on. I will have a look at Cordova, thanks Jason for the input 
On 26 August 2014 09:02, André Orvalho [email protected] wrote:
Hey guys,
Thanks for your input. I have done API’s before in rails and I understand
and follow the advices on using a versioned API. I think what Collin was
trying to say is in the beginning to get the app development going I should
be using the common API, and after build a version API.
In retrospect I think it is probably best to use a versioned api from
the beginning in the app, but initially you can just route this
through to existing actions in the rails app in order to get things
started, if that is appropriate (by adding the versioned routes to
routes.rb).
Colin
You will almost always find that as your mobile app and web app grow you
will require changes to the API. This is why a versioned API enable you
to not worry about crippling old mobile clients and move new clients
onto the new versioned endpoints.
It may be temping to just to “re-use” the existing Rails controllers –
and may in fact be the way to go if your app is small – but in a large
app this gets very messy very quickly.
Also if you are “re-using” the existing Rails controller because those
controllers contain domain logic, then you should refactor your domain
logic out of the controllers and into domain objects. Building more
controllers actually encourages you to do this, which in the end creates
a cleaner architecture (although I would caveat that it may be more work
up-front).
-Jason