Routable, an in-app URL router for iOS and Android (opens in new tab)

Very cool. But please don't use it. The de-facto architecture design proposed by the Android team is to use fragments for view separation. In my own app development workflow, I have not used multiple activity design for a really long time now. This is what you lose with external routing: 1. Better multiple screen size support: By housing all the fragments in one activity, you have control to hide/show/re-size fragments according to need since you have now have the fragment stack data in one activity. An external router doesn't make sense now, since the internal routing would still need to be handled by the activity. And if you write a router even for the internal stuff, then you need to address other concerns such as: backstack and bundles. 2. Single Top Activities: The Android app stack may have multiple instances of the same activity. When you route with a data path (user/id/1) which activity are you referring to? The Intent and PendingIntent classes have been developed over the years to face such weird idiosyncrasies of the platform. 3. Action Modes: The action mode api helps to create contextual actions. It gives you a nice separation of concern through callbacks. This glues the activity with fragments well. In two calls you setup a fragment and its contextual menus. With external routing you lose that or you handle it with more glue code.

I agree there are some cosmetic advantages through external routing, but develop any non-trivial Android app and you will find out, it's not always a good idea to fight the framework. In some cases maybe it is, for e.g this cool project: https://github.com/mitmel/SimpleContentProvider. Java is already too verbose. Wiring an external router means handling a lot of concerns yourself. Not cool.

What exactly is wrong with using Intents in Android? They would seem to be a far better mechanism for Android code, and also interoperate with the rest of the system (eg notifications).

"Long ago, there was an iOS library known as Three20."

What exactly happened with it? The website (http://three20.info/) seems to suggest that it hasnt been touched in years.

I wrote something similar a couple years back: https://github.com/aaronbrethorst/abrouter

The API is very similar to the one Aaron Brethorts (cocoacontrols) wrote. Seems pretty cool though, but I am not sure how it handles deep hierarchies of vc´s.

What if I route to a particular controller, what happens when I tap <back/dismiss> or how about segue animations?

Not complaining! Just curious. Will give it a shot now.

Checkout https://github.com/joeldev/JLRoutes by a former Apple iOS employee.

I have been building something similar for iOS called RESTMagic that does this automatically using the URL structure of your API.

http://RESTMagic.org http://github.com/RESTMagic/RESTMagic

If you build a twitter app (such as the example one with the project) and try and open a URL, the app handles it and opens the right view controller, if it doesn't exist it tries to get the json and match it with an HTML template. If the server just returns HTML is presents that. Magic.

The app even looks at your obj-c class prefix and looks if you made a subclass of the main view used for presenting HTML and uses that instead system wide.

Haven't posted it here yet but would love feedback, email address is on the RESTMagic page.

How do I do stuff like this?

-(id) initWithUser:(User *) user {

}

instead of passing around primitive data types?

Why completely ignore storyboards and XIBs on iOS?