How I built my first mobile app with Trigger.io
blog.self.li
blog.self.li
Where real value can be provided, however, is in providing turn-key modules that allow developers to drop in native controls to supplement their web applications. The biggest issue with hybrid mobile application development today is embedded webview performance, especially on older devices. Using a framework like Sencha works wonderfully for newer devices (it feels positively native on my iPhone 4s), but because they have to rely on javascript to fix elements and scroll certain sections on older devices, it ends up delivering a sub-par experience for those users (on older androids the scrolling performance is atrocious).
Trigger.io is currently offering API calls that allow you to drop in a tab bar and a navigation bar which are native components. These are the two elements in a mobile app that are most likely to require fixed positioning, so this frees the webview up to simply serve a normal web page with natural, native scrolling on all devices. This is essentially what Facebook is doing with their current app - fixed native navigation elements and scrolling UIWebViews. However, as we all know, Facebook's results have been less than satisfactory. They admit that this hybrid approach helped their developers iterate faster and be more productive, but instead of sticking with that strategy and figuring out clever ways to make it perform better, they've capitulated and are going full native.
If Trigger.io was able to solve that problem and make a hybrid HTML5/native app perform as well as any other native app, they would really have something there. My advice would be to figure out how to get UIWebViews to load faster and cache better, how to allow customization of native UI elements so that designers can deliver a unique, beautiful interface that scales across multiple platforms, and continue to provide best-in-class hooks into the native functionality on the leading platforms, such as dead-simple push notification integration. Focus less on competing with phonegap and more on solving the hybrid app problem.
I'm curious - how is that different from the way other frameworks allow plug-ins? As I understand it (perhaps not fully) plug-ins let you drop in chunks of native code where desired.
Because it's standard HTML with common frameworks, I then have my pick of docs/examples/tutorials/mailing lists on using those frameworks to build something bigger, rather than being stuck with e.g. only Android resources.
I think that's what the author is basing his positive evaluation on; he's got to the point where the Trigger.io technology has disappeared into the background and is just "magic". He recognizes the pros & cons (e.g. needing to be online to deploy), and is excited to use Trigger.io.
We're working on supporting more and more native features, such as the ones you describe. And you'll see from our blog that we're getting features out reasonably fast at the moment.
You can send a text message using our SMS module right now though:
BTW email sent :)
>I decided to go with Trigger.io to achieve my goal, as I wanted to spare myself endless hours spent on configuring environment (as opposed to PhoneGap/Appcelerator)
Huh? Have you tried phonegap? How does "click next on a couple of installers and extract a single zip file" take hours of configuration?
>Trigger.io provides you with a pleasant environment, where you don’t have to touch command line at all! It works as an app within your browser, from localhost. I do understand that a lot of folks may prefer “hacker-style” black terminal over Trigger’s clean and minimalistic web app, but for me clicking a button that i can see instead of typing a command is a much better experience, especially at the beginning.
I can't figure out what on earth he is trying to compare it to here. What html/js mobile app framework involves typing commands in "hacker style black terminals"? With phonegap you just click "run as android application" (or whatever you want to run it as).
This is how hard it actually is to setup phonegap: http://docs.phonegap.com/en/1.8.1/guide_getting-started_andr...
Regardless of whether you choose to point-and-click or use the command line, Trigger's web-based approach seems to have a huge advantage over all that installation/configuration. Heroku for cross-platform apps, as it were; of course you can assemble everything yourself, but it's a lot more work to get to the "it's easy now" stage which this blog gets to very quickly using Trigger.
It does seem Trigger are sending out T-shirts (see below) - it doesn't count as paid in my book, but then maybe the T-shirts are _really_ nice :-)
Uh huh? You've never used an IDE before? And that makes you think clicking next in an installer is hours of configuration?
>Trigger's web-based approach seems to have a huge advantage over all that installation/configuration
See, this is exactly what I mean. You are welcome to say "I prefer editing my code in a web browser", and I will certainly believe that (although I'll obviously assume you are insane). But trying to characterize the alternative of "using an editor" (which everyone already does for every other kind of development) as some arduous task is absurd.
>but it's a lot more work to get to the "it's easy now" stage which this blog gets to very quickly using Trigger.
No, it isn't. That's precisely the point. I just did it yesterday, that's why I know. It took 5 minutes to have a nicely documented example app up and running ready for me to edit it. I typed 0 commands. Deliberately misrepresenting software X is a bad way to sell people on software Y. It just makes you seem dishonest, and then your opinion isn't trusted.
We do provide a cloud build service so you don't compile the apps locally. You interact with that via command-line tools or our UI toolkit.
We frequently blog about app development ourselves at blog.trigger.io but this write-up is nothing to do with that and we certainly don't pay for 3rd parties to post on their blog. What made you think that's what's going on here?
As I said, the gross misrepresentation of your main competition.
But... to each their own. The Internet's haz one big opinion.
That said, it irks me that I'd have to pay $3600/year to support more than 2 platforms.