RESULTS FROM THE FEED READER EXPERIMENT
————————————————————————-
Continuing my work from last week I developed a simple FeedReader application (https://github.com/sayak-sarkar/FeedReader) to prototype the app developement methodology using the older Enyo 1.0 framework. The app worked great on webkit based browsers and as expected wouldn’t work on Gecko, primarily because enyo 1.0 was never meant to work on it. This little adventure however cleared up a lot of why’s and where’s of the previous WordPress for WebOS app for me.
ISOLATING DEVICE DEPENDENCIES
——————————————————
The next adventure that I embarked upon was identifying the various device depencies implemented earlier into the application that were no longer needed, isolate these, and replace them with placeholders for Firefox OS. At first this looked like an important challenge to me, however, as I went digging deeper into Enyo, I discovered that the latest Enyo update has already taken care of these problems and has altogether deprecated all usage of device specific palm apis, which essentially translated into a lot of time saving for the project as a whole.
This is a major problem solver for the project. Now, I don’t need to worry about how to port palm apis to web apis and stuff, all that is needed to be done is write the new app’s source code along with the package informations [package.js] required by enyo. Test it on the browser, if it works, add a manifest.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. [package information required by Web apps] and test it on the simulator and device!
NEXT STEPS
——————–
Even though my encounters with the latest and greatest of the enyo framework saved me a lot of headaches, it also revealed a major problem with my earlier development schedule for the project. The earlier development schedule that I was following revolved around a “Pick a module, port (read upgrade) it and go to the next one” approach. However, from what I learnt in the last few days, my approach to the project should be that of “Pick an older module, understand the concept, rewrite it from scratch using enyo 2.2”. Though the new schedule remains identical to the older one now, my work process now hopefully takes a turn for the better.
For the time being I’ve decided to use the enyo 2.2 bootplate to rewrite the app from scratch using the older one as a mere reference instead of trying to upgrade it, primarily because of the vast changes in enyo itself and the deprecation of the palm device apis. This also means that there would be a complete refactoring of the directory structure of the app itself.
IMPACT ON SCHEDULE
———————————–
Even though the impact of the change in work methodology on the schedule isn’t expected to be much, it still has resulted in me running a bit behind schedule this week in the fact that I’m yet to get started on the Compose function. I expect a slight domino effect of this on next week’s schedule too, however it should be in complete check by the end of the next week.
CURRENT WORK STATUS
————————————–
As of now, I’ve just started working on a brand new bootplate instance, and will start adding newer functions to it shortly (as per the project timeline). Once this foundation is built I’ll start commiting the code to the project repository.