Routable, an in-app URL router for iOS and Android

http://usepropeller.com/blog/posts/routable

by 10char • 13 years ago

100 16 13 years ago

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

seivan• 13 years ago

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.

10char2• 13 years ago

Thanks! Probably need more specifics on your concerns, but tapping back/dismiss should work as expected; Routable does have a `pop`[1] method, which will either pop the navigation stack or dismiss the visible modal controller. There's a configuration object for handeling transition and presentation options[2].

If any of that should be changed, definitely open an issue on the repo and we'll fix it

[1] https://github.com/usepropeller/routable-ios/blob/master/Rou...

[2] https://github.com/usepropeller/routable-ios#presentation-op...

niggler• 13 years ago

"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.

aaronbrethorst3• 13 years ago

Three20 was Joe Hewitt's baby when he was working on Facebook iOS stuff. After he stopped that, it seems like the project essentially went to seed. My understanding is that the 4.0 rewrite moved over to Nimbus (http://nimbuskit.info).

Three20 is hard to use, and is, for the most part, an all or nothing affair. You either use it throughout your whole app or not at all.

wallflower• 13 years ago

Three20 was in vogue (if it ever was) about three to four years ago. It was an ugly abstraction because it was very web-development centric. Most good developers I know have long abandoned Three20.

Really, you're not a real iOS programmer until you write your data abstraction yourself... and rewrite it two or three times based on lessons learned.

rogerbinns• 13 years ago

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).

10char2• 13 years ago

Nothing's necessarily wrong with them; but if you want to dynamically change the action of say a button from your server, then URL routing gives you a single string-based mechanism vs. writing some serpentine Intent creation logic in that method.

drawkbox• 13 years ago

The idea here is you can still use them, this just provides a higher level protocol/interface or standard that works across both, I love clean urls and context so I love this. Smart components, overarching director/handler/navigator, basically the web and game component architecture.

If you are making cross platform apps you have something like this but taking from web frameworks routing within apps is the best way to do this if you run from web, app, desktop and need a common system which the platforms then use system specific libs after.

The worst thing you can do making cross platform apps and games fast is to fall too in love with a great feature of one platform when you can standardize non essential stuff like this and simplify (i.e if you want server synced profiles using a cross platform solution over iCloud for instance, but maybe iCloud is an additional sync from your system on iOS but not the base). Then really beef up the areas where you do need to use system lock-in features for performance or familiarity.

king_jester• 13 years ago

This is really useful to hook into URLs matching a certain scheme when using an IntentFilter on an activity. If you know that emails or web-oriented content may be on the users device you can simply have the filter listen for the android.intent.action.VIEW action and set the pattern for the URL you expect. Having a class or couple of classes to parse that URL and route the user to the right app activity via Intents can be really helpful for more complex URLs.

rmoriz• 13 years ago

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

tejaswiy• 13 years ago

How do I do stuff like this?

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

}

instead of passing around primitive data types?

realrocker• 13 years ago

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.

bound008• 13 years ago

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.

vgrichina• 13 years ago

Why completely ignore storyboards and XIBs on iOS?

Routable, an in-app URL router for iOS and Android

Related Stories