OnRails.org

At first I thought “Wow, Adobe really messed up their communication”. They could have focused on what they are adding, strong support for HTML5 and CSS4, Adobe AIR for Mobile, and not on what they are removing, the Flash Player in the Browser. But then they also announced that they opened sourced Flex via the Apache Foundation. And the main stream media, the blogosphere, and many developers I know went crazy and said Flex is dead, it’s over, time to convert all your projects to HTML5.

At a second thought I think it’s pretty smart what Adobe did. The saying goes “If you can’t beat them, join them”. In fact the Flex against HTML fight wasn’t one where Adobe had anything to win from. So they just made it loud and clear and now they are saying “We are HTML5”. In fact detaching themselves from Flex in appearance allows them to ride the new HTML5 technowave and get in the news when they upgrade their tool, bring out new HTML5 component framework or acquire hot companies like PhoneGap and TypeKit. We are HTML5!!

Adobe has already two great tools for HTML5, Muse and Edge and needs to push them way further and also needs to create or acquire a great HTML component framework such as Sencha so they call build and sell new development tools as well as design tools for the new growing crowd of HTML5 developers.

So where does that leave Flash and Flex. I use a lot Flex in the enterprise, and that’s where Adobe just did the most damage in my eyes. Go now try to convince any CTO that Flex is a good idea. Flex is a mature framework and Adobe has a great enterprise offering, but it will be hard to convince anyone that Adobe is still behind that technology after the way they managed their communication. This said I think the move of Flex to the Apache open source foundation is a great one and if managed right will give Flex a good run for years to come. Flex is still a great choice for many enterprise projects and will remain so until a solid and widely adopted HTML component framework emerges. If Adobe is smart they could provide that offering.

Flex is also a great environment to develop “native” mobile applications that can run on iOS and Android. The forthcoming Flex SDK 4.6 will show that potential and it’s a great way to create cross platform mobile and tablet applications. Adobe will not kill Adobe AIR for the mobile as it’s a too appealing growth market. But that message didn’t get through to the main stream media.

As Adobe said Flash for the desktop for games and Adobe AIR for mobile will be here for a while. But Adobe has the most to gain if they become the major player in the HTML5 field by providing tools, framework and making the web standards evolve. And they are in a good position to get there. To achieve this goal it also means that they will refocus many of their development teams and this will impact Flash and Flex. Moving the Flex SDK and some of the key developers to the Apache Foundation will allow to continue to evolve the SDK regardless of Adobe’s new focus. The move a few years ago to the Flex Sparks components and the recent addition of the new mobile components provide a great and mature framework basis for a real open source effort which I believe will have a long life even if it will become a niche environment over the long run. Note I consider Ruby on Rails a niche market, a really great one to be in. Adobe has something great with Adobe AIR for mobile and this is the one area where they could even grow their developers basis if they get their message right. For me AIR for mobile/tablets and the Flex SDK 4.6 is one solution where I can build mobile apps faster than in any other environment and this will be a great business to be in, especially for the enterprise market.

The smart enterprises will realize that Flex is stable and here to stay for the long run, even if it’s not in the spotlight. They will start HTML projects in parallel to gradually improve their developer workforce and experience in this area. They will also realize that the HTML5 frameworks and coding technics are evolving so rapidly that it will be time consuming just to keep up. Also these frameworks are not as mature and complete as in the Flex ecosystem. Finding Flex developers is difficult, but finding great HTML/Javascript developers is even harder. This said, there is no denying that pretty quickly the HTML5 tools and frameworks will catchup with what Flex offers today in ease of development for enterprise applications.

Personally I’m looking forward to see how these HTML5/Javascript tools/libraries will evolve and will play with many of them.

So where does all this leaves you, the developer. Well, it’s for sure time to jump on the new HTML/Javascript bandwagon if you haven’t yet. I cannot see many companies starting new enterprise projects with Flex. If you are into mobile or tablet development give the new Flex SDK 4.6 a try, I believe there is a great potential for Flex to become a major player in the mobile development arena…targeting “native” applications and not the browser. Yep, your heard it here first ;-)

Enjoy,
Daniel

I created the MiFi app during the 360iDev conference on September 29th 2009 and submitted the app the same day. I released a fix a month later and didn’t touch the application since. I wasn’t using my Mifi card much until recently when I realized that the app wasn’t working on iOS 4.1. Then I checked the comments for the Mi-Fi app on the AppStore and realized that there where hundreds of comments of people that have the same issue. Sorry for being so late to realize that. Once I found that out I had to decide wether to remove the application from the store or fix it. So I reopened the project and realized that the way it was written wouldn’t work in the new Titanium SDK. Despite of the work I decided to rewrite/reorganized the code and voila…Mi-Fi 1.2 for iOS 4.1 should now work better than ever. I did not restyle the application, it could look better but it’s still functional. I also didn’t add any feature but at least you should get the battery and reception levels that are the most important features. Another feature I should add soon is to be able to set the ip address of your Mi-Fi card in case you changed from the default address.

What is stranger to me is how many people downloaded the application, knowing that it didn’t work on iOS4. About 400 downloads a week…man.. many people must be wondering what this application does and in fact did, as the reviews show. Well, that should be fixed. Sorry for the delay! Here is the weekly sales trend:

I also saw someone created a $2.99 version of the same app called MyMiFi it does the same thing but it has a nicer design I would say. Maybe I should give “paid” a try and will release this one for $.99 cents….or should I? The fact is that I really don’t care about selling 10 apps or even 100 apps at $.99…I maybe wouldn’t say the say if I sold 1000…So free it stays.

Now internally I had to rewrite the application as somehow the Titanium SDK changed enough that I couldn’t get it to work. So the new code is also a lot cleaner, so maybe I could add a few features soon:

In short this is the app.js

app.js
Titanium.include('resource.js');
Titanium.include('parser.js');
Titanium.include('controller.js'Titanium.include(‘resource.js’);

Titanium.include(‘parser.js’);

Titanium.include(‘controller.js’);
var controller = new Controller();

controller.start();
var webview = Titanium.UI.createWebView({url:‘index.html’, controller:controller});

var window = Titanium.UI.createWindow({fullscreen: true });

window.add(webview);

window.open();

As you see it loads the index.html which renders the main view. Index.html loads index.js which declares a listener to the update_view event.

Ti.App.addEventListener('update_view',function(e) {
  //..update the view using jquery based on e.state and e.info
})

The controller class checks every two seconds the state of the mifi card by getting the mifi status on the following url: “http://192.168.1.1/getStatus.cgi?dataType=TEXT”. It then parse the data (different for each version of the card) and creates a unified javascript structure and fire the update_view event:

     Titanium.App.fireEvent('update_view', {state:this.currentState, info:info});     

To make the calls to the mifi card I wrote a Resource class that abstracts the xhr request

     this.mifi = new Resource("http://192.168.1.1/getStatus.cgi?dataType=TEXT");
     this.mifi.index(this.mifiResult.bind(this));

Internally the resource uses the createHTTPClient and makes a standard ajax get call. I haven’t tried to use jquery’s .get function directly but assume it may not work with Titanium without some hacking…

          var xhr = Titanium.Network.createHTTPClient();               
          xhr.open("GET", url);    
          xhr.send();

So Titanium rocks and works pretty well, at least for many iPhone apps. Now let’s see how long it takes for the approval of another app that I submitted yesterday….

Enjoy!
Daniel Wanja

All right beside the cheesy title of this blog entry I did play a few weeks ago with Dashcode 3.0 to build an iPad app for a customer. After seeing the WWDC 2009 presentation on DashCode 3.0 I realized how much leaps and bounds DashCode made over the last two years. Checkout the quick screen cast demo here after and let me know what you think!

After looking into Dashcode 3.0 and doing some online search I found out that Jeff Watkins created several years ago coherentjs, a Cocoa inspired javascript framework, and he joined Apple to work on Dashcode. As you can see on http://coherentjs.org/ he since left Apple and revived Coherent as a multiple browser framework.

Based on the fact that WWDC 2010 is around the corner is it to be expected that the next version of Dashcode will be announced and among other things should provide an enhanced visual editor, enhanced frameworks, more components, improved datasource support, css transitions support, and iPad support. It could well be that Dashcode 4 is in fact what some refer to as Gianduia. The good thing is that we will find out soon.

Now let’s quickly look at what Dashcode currently offers, it’s pretty cool:

Dashcode 3.0 – An IDE to build HTML apps for iPad, iPhone and Safari from daniel wanja.

During 360idev (Sept 27-30) I wrote a small app to check the battery and connectivity level of my Mifi Card. I didn’t think many people would have an iPhone and a Mifi card. The iPhone is already 3g, but effectively there is not tethering allowed and the AT&T network is crapy. Nevertheless I thought my Mi-Fi App could be useful to others and along the way I would learn what it takes to submit an app to the AppStore.

I submitted the app on September 29th (during 360idev) and it was approved on October 12th. I submitted two other version since and last Monday I started collecting details of my experience of the AppStore, thoughts on the process, and various tibits around the web regarding this app and started writing this blog entry, but didn’t finished it as it was getting too late. Then last week I stumbled upon this article of Rogue Amoeba which detailed their experience with the store. I could relate on the feeling of waiting to know if you apps goes through or not, but fortunately the process took only two weeks for the first release. However I only had a Verizon card and was so eager to submit my app that I didn’t wait to find someone with a Sprint card. And of course the first version didn’t work with the Sprint card. Around the time the first version was approved I wrote a fix to support the Sprint cards and submitted that fix as version 1.1. Thanks to 2busy2blog</a> and <a href="http://twitter.com/pdsphil">pdsphil</a> for helping supporting the Sprint version. Then before it got approved Verizon put out a firmware update for their Mi-Fi card which of course broke version 1.1 (and 1.0). So I updated my Mi-Fi card and wrote a new version which additionally added support for the GSM version of the Mi-Fi card thanks to <a href="http://twitter.com/jkkmobile/">jkkmobile. That’s when I made a mistake…I wasn’t sure how to submit a new version when there is one waiting for approval so I just replaced the binary. What I didn’t know is that updating the binary puts you to the back of the queue. And I submitted version 1.1 two weeks before, and it took two more weeks to approve this “new” version 1.1 which was fortunately approved. Now I am not sure how they tested my app as it requires a piece of hardware. So maybe part of the two weeks is to find an approver that had a mifi card.

So all this approval process was new to me and indeed very frustrating when you are used to deploy several times a day fixes to your application in a “web” world. Now this is just a different paradigm and wether you like it or not thats’ the rules you need to play with (for the moment). That means several things. First your application must be tested way better before submitting and be more resilient to different scenarios. If you really have a bug that “Kills” you are just out of luck. It’s similar to developers writing games for the Nintendo DS…once you ship it…tough luck. Note the situation is slightly better, but if you have a fatal bug then people may never give it a second look, not time to cover up issues in a timely fashion. So Apple must find a way to allow fixes to be submitted and approved in a shorter time frame. Maybe two queues for approvals? Now I must admit the Rogue Amoeba guys had a different issue and they had to cripple their application just to have it approved and that for reasons that don’t make sense. Again this was an update to an application that was previously approved, so the wait time has to be way shorter and then again there needs to be some sort of “appeal” process where developers can justify why the app really should be approved.

Now you may argue why an approval process at all, why don’t let the user decide what to install. You may certainly not agree with me, but I like the fact that I can install apps and know they won’t reck my iPhone. I don’t think with an OS and an SDK like the iphone that this could be automated. Maybe an automation build where the apps are compiled by Apples and the compiler could check for any api call infringements? That would be fair, no? I don’t think no approval process is viable for the Apple as this would open the door to malware applications and even though many more savvy users would avoid bad apps the majority of users could end up just downloading any thing, would have issues, and that would be a bigger nightmare than facing the unhappy users. So in the mean time the iPhone development ecosystem is what it is and the platform is too cool to ignore. I’ll be working on several more iPhone apps over the next few months.

But will it make me rich?

As of today a little more than 2000 downloads which includes 695 upgrades. Wouhao, AT&T must really suck to have that many people that may potentially have an iPhone and a Mi-Fi card. Note these number are ridiculous compared to certain apps that get downloaded thousands a time a day, but hey, it’s all about learning here for me :-)

The interesting thing is that when Andy Ihnatko tweeted about it and Robert Scoble re-tweeted it the downloads made a nice bump:

“This is a must-have iPhone app for MiFi users: shows complete status of device. http://j.mp/2HBsso — big thanks to @2busy2blog – Andy Ihnatko”

And it shows of the iPhone community is active as many iPhone blogs picked on it, here are a few reviews:

• http://www.macsparky.com/2009/10/23/mifi-iphone-application
• http://www.gadgetreview.com/2009/10/mi-fi-iphone-app-monitors-your-mifis-battery-connections-and-more.html
• http://jkontherun.com/2009/10/23/iphone-app-monitors-mifi-3g-usage/
• http://www.gottabemobile.com/2009/10/23/do-you-use-mifi-with-your-iphoneipod-touch-theres-an-app-for-that
• http://www.iphonefreak.com/2009/11/mi-fi-app-for-the-iphone-ipod-touch-gets-an-update.html
• http://www.appstorehq.com/mi-fi-iphone-78445/app
• http://appsearch.justanotheriphoneblog.com/mi-fi-iphone-78445/app
• http://iphoneblips.dailyradar.com/story/iphone-app-monitors-mifi-3g-usage/
• http://www.zatznotfunny.com/2009-10/the-mifi-updates/
• http://technews.am/conversations/gottabemobile.com/iphone_mifi_app_needs_still_needs_some_work
• http://gearshrine.com/iPhone/opinion:iphone-app-monitors-mifi-3g-usage/

So this was a good first learning experience and hopefully there will be more.

Enjoy!
Daniel