I truly believe that the killer application is about two things: better access to people, better access to information. This means that there is no single killer app.
For some, the killer app is about access to their “corporate data”, to others is about access to email, for others is gaming – for many is about better communications, about better access to people, their friends and family.
A good example of better access to friends and family is presence and instant messaging on mobile handsets. I recently installed a pretty neat instant messenger application on my Treo 300. In many ways, this is a killer app – it provides presence information and access to my friends and family doesn’t matter where I am and vice versa (as long as I wish to), and of course, as long as I have network coverage.
Maybe the killer app is not about an app per-se, but about killer app enablers. Maybe it is about some kind of the killer framework, a framework that enables better access to people and/or information, a framework that enables or facilitates integration to the different data sources that are relevant an individual, a framework that brings information to the user. A framework that securely and proactively monitors and delivers information, and that properly presents that information based on the characteristics of a preferred channel (device or application), or of the channel currently being used. For a number of years I have been toying with these concepts. As the network and devices continue to become more advanced, realizing such concept is closer to reality.
Earlier this month the Data Sync API EG released an early draft of the
spec for (your) review… read below for details.
As you may know, data synchronization is one of the key approaches
(together with plain-ole HTTP, Web Services, SOA, etc) to integration
with back-end systems. Because of this, it is important to provide
feedback to make sure the API are rock solid.
The early draft review cycle closes on 1 January 2005.
The Early Draft Review Specification for JSR-000230 Data Sync API is now available for Review from the list of Early Draft Reviews page http://jcp.org/en/jsr/stage?listBy=community and also the JSR 230 detail page: http://jcp.org/en/jsr/detail?id=230
The Web Services APIs (WSA) for Java 2 Platform, Micro Edition (J2ME), as defined by the Java Community Process for the Java Specification Request 172 (JSR 172), are two independent optional packages for remote service invocation and XML parsing…
Read more at IBM DeveloperWorks.
Recently Nokia announced its vision for a networked service-oriented
architecture for mobile phones. I was finally able to find and read the
whitepaper. Some people have claimed this announcement as the most
important announcement at JavaOne, a pretty substantial claim. This
architecture is interesting indeed, but I can't
help it pointing out the following:
- The SOA architecture is Nokia-specific – let me remind mobile
application developers to avoid using vendor-specific APIs, as doing so hurts
- Creates J2ME API fragmentation – the API seems Nokia specific
com.nokia.web_services.*) and it doesn't seem to
promote the JSR-172 Web Services API (WSA) for J2ME. I
obviously have a problem with API fragmentation, especially when the
company was part of the expert group that defined the WSA standard
- It sounds cool, but it is it not necessarily practical – I also
have a problem with this, something that I have seem many times in
Read more at Comments on Nokia's SOA Announcement.
In response to Michael's blog entry “Write once, pray, and debug everywhere?”, which in turn was in response to Russ' blog entry, I think that:
True WORA will never happen. Companies will continue to differentiate themselves. Things have gotten much better though, and will continue to get better. This is because companies continue their innovation efforts, and are understanding the benefits of standardizing what at one point were proprietary interfaces, etc. These interfaces (specs) are at first imperfect thus contributing to the whole WORA issue – but over time, things should get better (as people get involved, try the technology and find issues).
I disagree a bit with the comment that “true WORA can only be realized when device manufacturers lose the drive to innovate”. Innovation will continue, first as proprietary extensions.
From the business perspective, I have encoutered many times (for specialized apps such as workforce management) that WORA may not be an issue at all! In those cases, companies typically adopt a specific device family/vendor, either because of cost and/or (proprietary) features of interest.
For the cases where portability is very important -> you better be smart when designing and building/putting together your deployable piece – yes, I agree w/ Michael that thru good practices (design patterns and dev or build processes) you can MINIMIZE the pain of DEPLOYING applications across different devices – but unfortunately not completely remove it.
To “profile” or not to “profile”. That is the question. There is the Mobile Information Device Profile (MIDP), and the Information Module Profile (IMP). And most recently the new Set-top box (STB) profile JSR was submitted to the JCP. In this essay we briefly explore CLDC-based profiles today, and the concern that CLDC-based profiles are being defined without proper forward-looking organization or structure. Over the last 5 years the J2ME platform, and especially the CLDC and MIDP, have become a proven application platform with millions of deployments – it is time to address any organizational issues now, before the problem gets compounded.
Read more at The Concern with CLDC-based Profiles Today…
A MIDlet class may manage its own logic and life-cycle, but often a better choice is for it to delegate these responsibilities to a finite state machine (FSM). An FSM provides a simple and effective means to control your MIDlet's life-cycle and overall application behavior. This article shows you how.
Earlier today the JSR-177 Security and Trust Services API for J2ME (SATSA) specification was approved for final release by the JCP Micro Edition Executive Committee.
Withouth trying to oversimplify this spec, in summary, SATSA defines how to integrate with Security Elements (SE) such as smartcards and SIM cards, by providing access and security (crypto) services. Access to the SE is via Java Card APDU or Java Card RMI and the Generic Connection Framework. Crypto API provides for signatures, digital signatures and so on.
You can get an idea on how to access an SE by reading the section “Using the Security and Trust Services API for J2ME” in my article An Introduction to Java Card Technology – Part 3, The Smart Card Host Application.
The Expert Group for JSR-000177 Security and Trust Services API for J2ME has completed its work and published the Final Release of the specification. The Final Release of the specification is available from the Java Community Process Web site's list of Final Releases: http://jcp.org/en/jsr/stage?listBy=final and also from the JSR 177 detail page: http://jcp.org/en/jsr/detail?id=177