Nope I didnt say it - Father of Java, James Gosling himself, did! Read full article here
Thursday, May 11, 2006
Friday, May 05, 2006
.mobi - good or bad?
Looking at the domain names of some of the popular mobile sites today, each of them seem to follow their own naming convention. This makes it almost impossible for a user to type in the URL directly on he mobile browser and expect to see mobile content, unless the site has server-side user-agent detection in place (like google.com for eg.) - which btw is not very maintainable in long term. The latest .mobi domains kind of addresses this problem as ICANN has placed content restrictions around .mobi registrations which mandates XTHML-MP content be served from .mobi domains. This enables a customer to confidently type .mobi URL - say company.mobi - and expect to see valid mobile content, without being worried about the possibility of getting flooded with the regular web content - wasting costly mobile data. Thus .mobi names do add value by providing initial navigation/getting users to the mobile site. However one could argue that users could use mobile search engines to get to the site rather than typing the URL in, but search results seldom guarantees that you get the right mobile URL.
On the down side, .mobi TLDs are not very mobile friendly in terms of the ease of use - 9 key presses just for the TLD alone isn't fun on a mobile phone.
Unfortunately standardization is something that isn't very popular at the moment in the mobile space - be it URLs, mobile content or even device browsers! Therefore adoption/non-adoption of this new .mobi standard in the mobile community is something we cannot predict right now but I do feel that getting the domains registered is the safest thing to do at this point.
On the down side, .mobi TLDs are not very mobile friendly in terms of the ease of use - 9 key presses just for the TLD alone isn't fun on a mobile phone.
Unfortunately standardization is something that isn't very popular at the moment in the mobile space - be it URLs, mobile content or even device browsers! Therefore adoption/non-adoption of this new .mobi standard in the mobile community is something we cannot predict right now but I do feel that getting the domains registered is the safest thing to do at this point.
Wednesday, April 12, 2006
Voice enabled apps
User input has always been a pain on mobile phones and always will be. I mean everybody wants to carry thinner and smaller when it comes to mobile phones. There is no way to incorporate a decent UI mechanism without sacrificing the size. Actually even in the moderately sized PDA touch screen phone with full expandable qwerty keypad that I carry (Cingular 8125), it is absolutely no fun when it comes to pulling out the stylus(or keyboard) and trying to input, say a userid/password combination.
This is exactly where the voice input comes into picture. It is so natural for one to speak into a mobile phone rather than try and type something into it. The critical factor ofcourse here is the processing power of the mobile phones - unfortunately no where near what it takes to run an efficient speech recognition system right now. Given the "size" factor mentioned above and the "battery life" factor it probably will never get there. However voice recognition is perfectly do-able on server side. With the appropriate tech on the device side to reduce the sampling rate thereby keeping bandwidth usage within limits and a sophisticated server side VR system probably with an add-on personalization engine, voice enabled apps could be definitely the next big thing in mobile space! Maybe voice enablement could be offered by the service providers to application providers - or there could be third party voice gateway providers similar to SMS providers. Or it could be application provider hosted just like regular VR gateways (secure apps would probably need to do this). There are tons of possibilities out there.
I wonder whether Google’s latest voice search patent has anything in it related to this.
This is exactly where the voice input comes into picture. It is so natural for one to speak into a mobile phone rather than try and type something into it. The critical factor ofcourse here is the processing power of the mobile phones - unfortunately no where near what it takes to run an efficient speech recognition system right now. Given the "size" factor mentioned above and the "battery life" factor it probably will never get there. However voice recognition is perfectly do-able on server side. With the appropriate tech on the device side to reduce the sampling rate thereby keeping bandwidth usage within limits and a sophisticated server side VR system probably with an add-on personalization engine, voice enabled apps could be definitely the next big thing in mobile space! Maybe voice enablement could be offered by the service providers to application providers - or there could be third party voice gateway providers similar to SMS providers. Or it could be application provider hosted just like regular VR gateways (secure apps would probably need to do this). There are tons of possibilities out there.
I wonder whether Google’s latest voice search patent has anything in it related to this.
Wednesday, January 18, 2006
Blackberry Woes
RIM blackberry can be pretty troublesome when it comes to deploying J2ME apps. First of all they have the custom .alx and .cod files instead of the standard .jad and .jar files. These need to be generated using the RIM supplied tools and IDE (which is not Eclipse based!) However the device will automatically do the conversion if you use OTA deployment. Then there is the weird blackberry form factor - very good for email, but sucks for J2ME developers. Well.. unless you are maintaining blackberry specific versions. I think the screens on the newer 710x series and 8700 series are much better when compared to the 7xxx ones.
Even bigger pain is the connectivity, especially if your app need secure connections (https/TLS, SSL). Given that the J2ME support for HTTP spec is only partial (lack of "official" cookie support, DELETE, PUT methods, 302 redirect response handling etc), RIM makes it even more difficult with their custom connectivity options. First of all, if you are an enterprise customer, you are almost certain to have Blackberry Enterprise Server (BES) enabled. In that case all your connections by default go into your corporate intranet via BES and in order to connect to the outside world, you need Mobile Data Service (MDS) enabled within BES! Sometimes enterprise policies might not allow enabling MDS service altogether or might be restricted. Even if MDS is enabled, it might do stuff like handling redirect and cookie handling on its own - which actually might impact the way your application is designed to work. (I have seen at least the MDS simulator behaving like this). Now if you are enterprise customer and if you don’t have MDS enabled, you are basically dependent on the carrier's support for WAP gateway/proxy or direct TCP access. If your app needs direct connection and cannot use the WAP gateway due to security reasons (WAP gap), you almost have to break the app's portability by having to append an "invalid" (it uses a ";" instead of "?" Or "&") parameter to your URLs while opening the connection! For e.g.: https://myserver.com/myapp?myparam=true;deviceside=true. (Now if you think that's weird, you should see the URL for the WAP proxy!!!) . The direct connection would work only if it is supported by the carrier (Check this link for details on carrier support and config info - very useful). Anyways, your app can still be portable, by adding the extra stuff only for blackberry devices - thanks to the "microedition.platform" system property.
For non-enterprise customers RIM provides an additional service called Blackberry internet service (which is nothing but a publicly hosted BES). However the access via BIS is open only to browsers - so far. The claim is that BIS shields the connectivity from any carrier specific configuration that needs to be set on the device (APN settings etc) which is true, (the BIS settings could be specified programmatically, again non standard I suspect) and might be useful especially when you are roaming. Also there is plenty of other custom APIs that RIM provides for encryption, XML manipulation and UI. However accesses to some of these are restricted only to apps signed with RIM certs - which is not free! Interesting stuff really, but I would rather wait for the RIM-NTP patent tussle to settle down before I dig in into those!
Even bigger pain is the connectivity, especially if your app need secure connections (https/TLS, SSL). Given that the J2ME support for HTTP spec is only partial (lack of "official" cookie support, DELETE, PUT methods, 302 redirect response handling etc), RIM makes it even more difficult with their custom connectivity options. First of all, if you are an enterprise customer, you are almost certain to have Blackberry Enterprise Server (BES) enabled. In that case all your connections by default go into your corporate intranet via BES and in order to connect to the outside world, you need Mobile Data Service (MDS) enabled within BES! Sometimes enterprise policies might not allow enabling MDS service altogether or might be restricted. Even if MDS is enabled, it might do stuff like handling redirect and cookie handling on its own - which actually might impact the way your application is designed to work. (I have seen at least the MDS simulator behaving like this). Now if you are enterprise customer and if you don’t have MDS enabled, you are basically dependent on the carrier's support for WAP gateway/proxy or direct TCP access. If your app needs direct connection and cannot use the WAP gateway due to security reasons (WAP gap), you almost have to break the app's portability by having to append an "invalid" (it uses a ";" instead of "?" Or "&") parameter to your URLs while opening the connection! For e.g.: https://myserver.com/myapp?myparam=true;deviceside=true. (Now if you think that's weird, you should see the URL for the WAP proxy!!!) . The direct connection would work only if it is supported by the carrier (Check this link for details on carrier support and config info - very useful). Anyways, your app can still be portable, by adding the extra stuff only for blackberry devices - thanks to the "microedition.platform" system property.
For non-enterprise customers RIM provides an additional service called Blackberry internet service (which is nothing but a publicly hosted BES). However the access via BIS is open only to browsers - so far. The claim is that BIS shields the connectivity from any carrier specific configuration that needs to be set on the device (APN settings etc) which is true, (the BIS settings could be specified programmatically, again non standard I suspect) and might be useful especially when you are roaming. Also there is plenty of other custom APIs that RIM provides for encryption, XML manipulation and UI. However accesses to some of these are restricted only to apps signed with RIM certs - which is not free! Interesting stuff really, but I would rather wait for the RIM-NTP patent tussle to settle down before I dig in into those!
Subscribe to:
Posts (Atom)