Well as most people following Palm now know, we get 3D games immediately with Flash and some new webOS phones in the near future. These are the types of moves that Palm needs to be making in order to survive. Those were all great announcements, but they didn't directly impact our apps gDial Pro or Visual Voicemail.
The gift that we got from the CES announcements was that Palm was going to immediately allow developers to start distributing their apps using the web delivery method. For us, this was the biggest game changing announcement as it means we can update our apps and deliver those updates to our customers almost immediately. Anyone who has developed apps for webOS and published them in the App Catalog knows that from submit to publish can have a significant time delay.
We update our apps all the time with new features, bug fixes, polish, etc and we really wanted to be able to get each and every one of these updates out to our users with or without Preware. We weren't able to do this previously as we had to pick and choose which releases we would submit to Palm as it was likely that it would take 1-2 weeks for those updates to get reviewed and pushed out.
That has totally changed with the new web distribution model that Palm has enabled. We can keep on pushing select releases to the App Catalog for new users, but anyone who wants to get every update as soon as possible can now move over to our "Rapid Release" version which is web distribution only. It is the same app as in the catalog, but all updates get pushed as soon as they are tested right out to users.
One instance in the past where this would have been useful is when Google changed their Google Voice API and we fixed the bug in a couple of hours. It then took ~2 weeks for the App Catalog users to get this update due to the review process. If that were to happen now, we could have that fix up and live through web distribution just as fast as we could push it.
Kudos to Palm on implementing this as it puts them a bit closer to the realtime app distribution that Android provides for its developers. The only difference is that users must now switch over to a the Rapid Release version after having used the regular release vesion in the catalog which is added hassle for them.
And that brings me to the one area where I would like to see some improvement. Provide some mechanism so that we can do the realtime updates to the catalog apps. Even if the user gets prompted to enable the functionality and has it explained that the updates have not yet been reviewed by Palm. Basically use the App Catalog as just a sales tool that developers can pay to list in with some badge or something to indicate whether Palm has reviewed the app/update yet.
Otherwise the new distribution is great.
The other big announcement was the PDK which will allow for developers to write pieces of their apps in native code. Doesn't help us much, but my assumption would be that anyone using PDK is able to bypass some of the restrictions that are currently in place in the webOS API for accessing universal contacts, calendar, and other data. If the PDK allows this, then my hope is that they plan to also open this up in the webOS SDK. This is important to us to allow native universal search within gDial Pro of all contacts. We want our dialing to work just like the native phone. Also, it might be possible with the PDK to implement some of the more advanced features users have been clamoring for, like auto-answering the call in from Google Voice when you are using the web dial method of making outgoing calls.
All in all good announcements for the users and developers.
Showing posts with label webOS. Show all posts
Showing posts with label webOS. Show all posts
Saturday, January 9, 2010
Wednesday, December 23, 2009
Happy Holidays
It is that time of year again where every business grinds to a halt for the 2 weeks that overlap Christmas and New Years. You will notice that there haven't been many releases lately and that is somewhat due to this entrance into the holiday season.
What's next:
As for the New Year and future plans, it is pretty unclear at this point. We have two releases of software now with both gDial Pro and Visual Voicemail that we would like to continue to polish over the coming months. One of the things we have started to hear around the blogosphere is that Google is preparing to finalize the launch of Google Voice for consumers soon in the New Year. What this means for our software will depend on what their "release" consists of. My hope is that with a release they also put out an official API for Google Voice which will allow for us to improve the experience for our users on webOS as we will be able to focus more on features instead of adaptations to changes within the unofficial API's.
What else:
We also get a lot of questions as to what else we are working on. While we do have some ideas, we are looking towards our users and fans to give us suggestions on not only what features they would like to see in our current software, but what they want in new software that is not being taken care of by other developers already in the App Catalog. So please let us know.
Predictions:
Everyone likes to make predictions for the new year and we are no different. So here are my thoughts on where things are heading in tech:
What's next:
As for the New Year and future plans, it is pretty unclear at this point. We have two releases of software now with both gDial Pro and Visual Voicemail that we would like to continue to polish over the coming months. One of the things we have started to hear around the blogosphere is that Google is preparing to finalize the launch of Google Voice for consumers soon in the New Year. What this means for our software will depend on what their "release" consists of. My hope is that with a release they also put out an official API for Google Voice which will allow for us to improve the experience for our users on webOS as we will be able to focus more on features instead of adaptations to changes within the unofficial API's.
What else:
We also get a lot of questions as to what else we are working on. While we do have some ideas, we are looking towards our users and fans to give us suggestions on not only what features they would like to see in our current software, but what they want in new software that is not being taken care of by other developers already in the App Catalog. So please let us know.
Predictions:
Everyone likes to make predictions for the new year and we are no different. So here are my thoughts on where things are heading in tech:
- Apple tablet: You can bet on it being released at some point in 2010. The costs on tablets is finally getting into the area where a high quality, functional tablet is possible.
- Google takes over the world: If you are using our software, then you are already using them for phone service. Not internet, but phone, who would have thought. Get ready for them to move into more areas. They have already said they will make Google Docs as good as MS Office and I would expect them to enter even more areas of your life aka (Chrome OS and Android).
- webOS: Well, this is the biggest fog out there for me. 2010 will either define their rebirth or signify their end. Ares is a nice start to being revolutionary, but will developers take to it or will it lead to App Catalog spam of low quality apps? The tech guys at Palm that I have met are a great group with a vision that makes sense, but will the business people allow them to execute that vision and can they do it fast enough to stay relevant in the increasing Android tidal wave?
What do you think is the most exciting upcoming tech product/service?
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.
Subscribe to:
Posts (Atom)