I hadn't looked at the ratings in the app catalog for awhile because I knew they would be bad with the broken version of gDial Pro that is in there. Well, against my better judgement, I went and looked at the reviews and they are bad :(
In case anyone using gDial Pro from the app catalog sees this post, let me provide an explanation of the problem.
Sometime around November 17th or 18th:
Google changed their API on Google Voice. I was notified of the change through my own use of the app breaking as well as users on the PreCentral forums.
November 18th:
Submitted a fixed version of the app to Palm for update with a notice to my account rep that it was urgent and that the version in the App Catalog was essentially broken.
Since November 18th - November 28th:
Waiting on app approval at Palm. Again the app is already fixed, but that update is held up somewhere in the approval queue at Palm and everyone else is suffering due to this.
It is tough as a software developer to keep a program updated when you are using an undocumented API from Google who moves "quick" and I am stuck with a software approval queue that moves "slow". The fix was completed in a matter of hours, but the approval is taking weeks.
Sorry everyone, but once you see the update notification from Palm, you can be assured that web dial works again in the software. Until Google releases an API to Google Voice, we will likely have more speed bumps like this where they make a change and I have to adapt to it and re-release. If we could get a faster approval process, then most people would probably not even notice the problem, but that is on Palm.
Saturday, November 28, 2009
Saturday, November 21, 2009
My thoughts on "Palm for sale?"
So Precentral put together a round table question of their editors on who they think would be a good buyer for Palm if Palm was for sale. Round Table: Palm for sale?
I wanted to throw out my own thoughts on it as I have been looking at all of the mobile platforms and devices lately.
For me the logical buyer for Palm would be a current Android device maker. Be it Samsung or Motorola, or one of the others. As I look at the development model for webOS, I really like it (other than some missing debug tools ) and I really don't like the competing development styles as much. What I think would make sense would be for some large handset maker to buy up Palm and port webOS to Android for their devices. Device makers are already able to put their own skin's on Android and add quite a bit of their own functionality. Also, with devices like the nook running Android underlying what is to be a full featured eReader that doesn't even look like the Android OS, you can do some massive customization to the underlying OS while leveraging the unstoppable Android train of developers and advances that is taking place. Let others manage the OS for you and just focus on your differentiating factor, webOS and your hardware.
It shouldn't be hard to port webOS to Android as it already runs on the custom Linux image generated by Palm, so why not just go all the way and make it an add-on to Android? I am not saying release it for other handset makers to use or all Android users. Just emulate what HTC is doing, build on Android and add on top your beautiful webOS front on custom Palm hardware for the best mobile experience while simultaneously cutting out the significant cost of maintaining your OS to a lower level like you do now.
Motorola, if you are listening, webOS beats MOTOBLUR. Pick up the team of forward thinking guys at Palm and really make a run at iPhone. If I could have access to not only the Android Market but the Palm App Catalog on the same phone, we'd be cooking with fire and it solves that low-level API issue people have been mentioning. I'm just saying.
I wanted to throw out my own thoughts on it as I have been looking at all of the mobile platforms and devices lately.
For me the logical buyer for Palm would be a current Android device maker. Be it Samsung or Motorola, or one of the others. As I look at the development model for webOS, I really like it (other than some missing debug tools ) and I really don't like the competing development styles as much. What I think would make sense would be for some large handset maker to buy up Palm and port webOS to Android for their devices. Device makers are already able to put their own skin's on Android and add quite a bit of their own functionality. Also, with devices like the nook running Android underlying what is to be a full featured eReader that doesn't even look like the Android OS, you can do some massive customization to the underlying OS while leveraging the unstoppable Android train of developers and advances that is taking place. Let others manage the OS for you and just focus on your differentiating factor, webOS and your hardware.
It shouldn't be hard to port webOS to Android as it already runs on the custom Linux image generated by Palm, so why not just go all the way and make it an add-on to Android? I am not saying release it for other handset makers to use or all Android users. Just emulate what HTC is doing, build on Android and add on top your beautiful webOS front on custom Palm hardware for the best mobile experience while simultaneously cutting out the significant cost of maintaining your OS to a lower level like you do now.
Motorola, if you are listening, webOS beats MOTOBLUR. Pick up the team of forward thinking guys at Palm and really make a run at iPhone. If I could have access to not only the Android Market but the Palm App Catalog on the same phone, we'd be cooking with fire and it solves that low-level API issue people have been mentioning. I'm just saying.
Thursday, November 19, 2009
Google Voice API Change
Just to give everyone some insight into why gDial Pro in the App Catalog is currently broken. It appears that Google Voice changed their API and since it isn't a publicly released/documented API there is no way to let 3rd party developers know in advance when they change it and its not really their responsibility at this point.
In this case they changed the method call to do a "webdial" and didn't make the new method backwards compatible, so as a result it fails for anyone who didn't move to the new API call. I was able to quickly find the issue, and repair gDial Pro, but now it is in queue for approval at Palm before being pushed to the App Catalog.
This is the real reason that we developers need a much quicker way to push our updates and changes to users. When we discover a bug, we can fix it immediately, but then the update doesn't get to our end users until it is reviewed by Palm. I know they are supposed to be releasing a way to directly get updates to our end users shortly so this should be a thing of the past in the coming months.
Paul Graham, an old LISPer, has written a post that basically echo's this same issue on Apple. Here it is for your perusal.
Apple's Mistake
Palm, please make sure to read this and listen to what he is saying as it exactly echo's how I feel and what I was saying in my past post. I know you guys are already on the path to speed up the deployment, but I just felt it important to reiterate what Paul Graham states as the reason for "karma leak" at Apple with their iPhone developers.
In this case they changed the method call to do a "webdial" and didn't make the new method backwards compatible, so as a result it fails for anyone who didn't move to the new API call. I was able to quickly find the issue, and repair gDial Pro, but now it is in queue for approval at Palm before being pushed to the App Catalog.
This is the real reason that we developers need a much quicker way to push our updates and changes to users. When we discover a bug, we can fix it immediately, but then the update doesn't get to our end users until it is reviewed by Palm. I know they are supposed to be releasing a way to directly get updates to our end users shortly so this should be a thing of the past in the coming months.
Paul Graham, an old LISPer, has written a post that basically echo's this same issue on Apple. Here it is for your perusal.
Apple's Mistake
Palm, please make sure to read this and listen to what he is saying as it exactly echo's how I feel and what I was saying in my past post. I know you guys are already on the path to speed up the deployment, but I just felt it important to reiterate what Paul Graham states as the reason for "karma leak" at Apple with their iPhone developers.
Friday, November 13, 2009
Threads please
I like to use these blog posts to put out my experiences while working with webOS on gDial Pro and also to lobby for what I want as a developer from the Mojo SDK.
If you know Javascript, then you know that it is single threaded. (Except for WorkerPool in Gears)
For most usage cases this is no big deal as it offers plenty of asynchronous functionality and by being single threaded you can avoid some of the thorny issues with locks, etc that threads bring with them. This is a good thing. The problem I am currently having is that Javascript is now being used for a full application which consists of a User Interface and then other operations that run in the background at various intervals.
With a single thread, I have had to do some copious balancing of work being done by the program and leaving processing open for the User Interface to remain responsive. The type of work being done in the "background" is searching contacts for universal search, loading new history, loading new contacts, etc. This is stuff that is coded in gDial Pro and so asynchronous is not enough. I have had to wrap what should be step by step logic into asynchronous mish-mash to keep any of the logic from interfering with the User Interface so that users don't see a laggy interface when clicking buttons, seeing a spinner, and anything else.
Just to give some perspective on this, if you do a loop through 300 items and don't do much work at all in the loop, it will lock up the UI during this loop. The spinner stops, clicks don't work, nothing. On a desktop this isn't an issue as the loop takes almost no time, but on a mobile device like the Pre or Pixi, well you get the point. The time taken to process is longer and so is the unresponsiveness then of the UI unless you break this loop up into an asynchronous process. That leads to questions like how many iterations should I do before returning control to the UI....This starts to sound an awful lot like writing a thread scheduler without know what other threads are running in the OS.
My point of this post is to convince Palm to implement something like the WorkerPool from Gears into the Mojo SDK. Some people would say why add threads when you can code around it, but from my perspective, let me choose to use a more advanced tool like threads if I need them, and I REALLY NEED THEM. I would rather keep the logic of my code straightforward and let it run in a low priority thread then try to do my own thread management using asynchronous callbacks (This is not fun by the way).
I spoke with some engineers at Palm about this while out there for the Sprint Developer Conference, but please make it a priority. Complex apps would be easier to write with threads or something simulating threads. Even if it continued to be a single thread but with scheduling built into the webOS piece that would be fine (ie yield support). Just don't force me to schedule threads as I don't have access to know what else is happening on the device to do it and I really don't want to anyways.
For the time being I will continue to simulate threading where it doesn't exist.
If you know Javascript, then you know that it is single threaded. (Except for WorkerPool in Gears)
For most usage cases this is no big deal as it offers plenty of asynchronous functionality and by being single threaded you can avoid some of the thorny issues with locks, etc that threads bring with them. This is a good thing. The problem I am currently having is that Javascript is now being used for a full application which consists of a User Interface and then other operations that run in the background at various intervals.
With a single thread, I have had to do some copious balancing of work being done by the program and leaving processing open for the User Interface to remain responsive. The type of work being done in the "background" is searching contacts for universal search, loading new history, loading new contacts, etc. This is stuff that is coded in gDial Pro and so asynchronous is not enough. I have had to wrap what should be step by step logic into asynchronous mish-mash to keep any of the logic from interfering with the User Interface so that users don't see a laggy interface when clicking buttons, seeing a spinner, and anything else.
Just to give some perspective on this, if you do a loop through 300 items and don't do much work at all in the loop, it will lock up the UI during this loop. The spinner stops, clicks don't work, nothing. On a desktop this isn't an issue as the loop takes almost no time, but on a mobile device like the Pre or Pixi, well you get the point. The time taken to process is longer and so is the unresponsiveness then of the UI unless you break this loop up into an asynchronous process. That leads to questions like how many iterations should I do before returning control to the UI....This starts to sound an awful lot like writing a thread scheduler without know what other threads are running in the OS.
My point of this post is to convince Palm to implement something like the WorkerPool from Gears into the Mojo SDK. Some people would say why add threads when you can code around it, but from my perspective, let me choose to use a more advanced tool like threads if I need them, and I REALLY NEED THEM. I would rather keep the logic of my code straightforward and let it run in a low priority thread then try to do my own thread management using asynchronous callbacks (This is not fun by the way).
I spoke with some engineers at Palm about this while out there for the Sprint Developer Conference, but please make it a priority. Complex apps would be easier to write with threads or something simulating threads. Even if it continued to be a single thread but with scheduling built into the webOS piece that would be fine (ie yield support). Just don't force me to schedule threads as I don't have access to know what else is happening on the device to do it and I really don't want to anyways.
For the time being I will continue to simulate threading where it doesn't exist.
Wednesday, November 11, 2009
Closure and webOS
So I have spent the last few days messing around with Closure, Google's new javascript library, compiler, and templating.
First, the why
The Closure compiler from Google promises to do code optimization, inlining, and trimming all in one. So theoretically it would make the javascript faster and smaller which is a good thing especially when working on a mobile platform.
My first goal was to get gDial Pro to compile using the Closure compiler and its standard optimization level. This can be simple, just compiling each js file individually, which doesn't really give too much gain since a lot of the optimizations need to see all of the js code in one file in order to really do its magic.
So it should have been simple right, just pass in each js file on one line to the Closure compiler and let it work its magic which it did. The resulting code would not run though as it simply concatenates all the files together in the order passed in and compiles. In the gDial Code there are some js files that need to load in specific order after other files. So when they concatenate willy nilly, you get broken code as some objects/functions were not defined before where they were being used.
So to make it work, I needed to concatenate all of the javascript files in the order that they need to load and then run the compiler. This was easier said than done as I wanted a generic solution that didn't require me to hand edit the build file every time I added in a new javascript file or changed the load order. The solution is that the sources.json file already has my code listed in the order it needs to load. So, I created a sed command to parse that file for the filenames since they are already in order and concatenate them together, then run the Closure compiler.
Also, after this happens, all of the code for the app is now in a single output file and so that same sources.json file need replaced with a file referencing the single .js file that we have output from the Closure compiler.
And then it works!!!!
Gotchas
You can't use the object oriented inheritance from the Prototype library. (i.e. Class.create). The reason is due to the way that you make calls to super class functions in their system. They require that the function receive a special parameter named '$super'. Closure changes the name of all parameters to short 1 letter names for space reasons and so this '$super' variable will have its name changed which breaks the inheritance.
You can get around this by using the excellent Dojo Library and its class inheritance system which doesn't require the use of special variable names and works fine with the Closure compiler.
Also, I only apply the Closure compilation when building my production releases of the software as the name/file mangling would be a nightmare for use in debugging. So I debug my code and then I have a build script which runs the compiler on the code and builds my packages for distribution.
Forget about trying to run the compiler in advanced optimizations mode. Won't work as it really needs to be run on a single file with ALL of the javascript code and the Mojo Framework js code as well as their version of prototype get included into the app separately. I am sure someone will come up with a solution to this in the future, but for now I wouldn't recommend even trying it for the average app developer.
Also, for the same reasons, using the Closure Library is a no go as well. It has a package system that dynamically loads the js files it needs, but due to the way the webOS apps are loaded, the package system doesn't seem to work.
Worth it?
Tough question. Now that I am done with implementing it, the hard work is done and I will likely continue to use it as I plan to migrate to the Closure Library and Advanced Optimizations as techniques are discovered to make them work with webOS.
As to whether there is any performance increase in the resulting code, I am not sure as I just put it out there to the Homebrew community and I am awaiting feedback from all of the users on their experiences with the app. It was pretty optimized before and I was already minifying code with the YUI Compressor.
Only time will tell whether it was worthwhile.
First, the why
The Closure compiler from Google promises to do code optimization, inlining, and trimming all in one. So theoretically it would make the javascript faster and smaller which is a good thing especially when working on a mobile platform.
My first goal was to get gDial Pro to compile using the Closure compiler and its standard optimization level. This can be simple, just compiling each js file individually, which doesn't really give too much gain since a lot of the optimizations need to see all of the js code in one file in order to really do its magic.
So it should have been simple right, just pass in each js file on one line to the Closure compiler and let it work its magic which it did. The resulting code would not run though as it simply concatenates all the files together in the order passed in and compiles. In the gDial Code there are some js files that need to load in specific order after other files. So when they concatenate willy nilly, you get broken code as some objects/functions were not defined before where they were being used.
So to make it work, I needed to concatenate all of the javascript files in the order that they need to load and then run the compiler. This was easier said than done as I wanted a generic solution that didn't require me to hand edit the build file every time I added in a new javascript file or changed the load order. The solution is that the sources.json file already has my code listed in the order it needs to load. So, I created a sed command to parse that file for the filenames since they are already in order and concatenate them together, then run the Closure compiler.
Also, after this happens, all of the code for the app is now in a single output file and so that same sources.json file need replaced with a file referencing the single .js file that we have output from the Closure compiler.
And then it works!!!!
Gotchas
You can't use the object oriented inheritance from the Prototype library. (i.e. Class.create). The reason is due to the way that you make calls to super class functions in their system. They require that the function receive a special parameter named '$super'. Closure changes the name of all parameters to short 1 letter names for space reasons and so this '$super' variable will have its name changed which breaks the inheritance.
You can get around this by using the excellent Dojo Library and its class inheritance system which doesn't require the use of special variable names and works fine with the Closure compiler.
Also, I only apply the Closure compilation when building my production releases of the software as the name/file mangling would be a nightmare for use in debugging. So I debug my code and then I have a build script which runs the compiler on the code and builds my packages for distribution.
Forget about trying to run the compiler in advanced optimizations mode. Won't work as it really needs to be run on a single file with ALL of the javascript code and the Mojo Framework js code as well as their version of prototype get included into the app separately. I am sure someone will come up with a solution to this in the future, but for now I wouldn't recommend even trying it for the average app developer.
Also, for the same reasons, using the Closure Library is a no go as well. It has a package system that dynamically loads the js files it needs, but due to the way the webOS apps are loaded, the package system doesn't seem to work.
Worth it?
Tough question. Now that I am done with implementing it, the hard work is done and I will likely continue to use it as I plan to migrate to the Closure Library and Advanced Optimizations as techniques are discovered to make them work with webOS.
As to whether there is any performance increase in the resulting code, I am not sure as I just put it out there to the Homebrew community and I am awaiting feedback from all of the users on their experiences with the app. It was pretty optimized before and I was already minifying code with the YUI Compressor.
Only time will tell whether it was worthwhile.
Wednesday, November 4, 2009
Whew back from Sprint Dev
Let me just say that the Sprint Developer Conference was great. There are a ton of good people developing apps for webOS and the guys from Palm are okay too :)
If you have read my previous post Get out of my fast lane you will know that I laid out 3 steps that Palm can do quickly to empower its developers to create even better apps. I was happy to find out at the conference that they do intend to do all 3 of these items and in fact they have already started following through on them. I believe they know they need to move quickly in order to compete with Apple and Android. Only the future will tell how it plays out, but the OS is still my favorite even when looking at Android 1.6 and iPhone 3.1. Now Android 2.0 might change my opinion when it brings a lot of the unique "Synergy" features that currently only webOS offers.
If you have read my previous post Get out of my fast lane you will know that I laid out 3 steps that Palm can do quickly to empower its developers to create even better apps. I was happy to find out at the conference that they do intend to do all 3 of these items and in fact they have already started following through on them. I believe they know they need to move quickly in order to compete with Apple and Android. Only the future will tell how it plays out, but the OS is still my favorite even when looking at Android 1.6 and iPhone 3.1. Now Android 2.0 might change my opinion when it brings a lot of the unique "Synergy" features that currently only webOS offers.
Subscribe to:
Posts (Atom)