Sean Sheedy's Blog: Community: Mobile & Embedded Archives

The MEDD conference was exactly what I thought it would be: learning about cool stuff (SunSPOTS!), meeting old friends and making new ones. And it turned out that one topic stood out above the rest - confronting fragmentation in the mobile space.

Looking at the lightning talk feedback we find the most highly rated lightning talk was possibly Terrence Barr's "Do We Need a Mobile Developer Alliance"? Were the ratings also votes for making such an alliance a reality?

SunSPOTs and ham radio

Posted by sean_sheedy on January 23, 2008 at 03:41 PM | Permalink | Comments (2)

This week I decided to drive from San Diego to Santa Clara to this week's MEDD conference rather than fly home and back again. This gave me the opportunity to try out a new ham radio product called the TinyTrak4 which is about to be released by its creator, Byon Garrabrant.

The TinyTrak4 provides me with an APRS setup in my car to track my position as I moved along. (I also beaconed that I could be reached by voice on 144.39 MHz, which is the ham radio national calling frequency for two meters, and kept a second radio on for that purpose.)

Links:

Present location
Ham stations near me
APRS users around the country

Now, there is a really cool product called the TinyTrak4 which has been through a year of beta testing (that's my TT4 on Byon's web page) and is about to go live. You hook up a GPS receiver to the TT4 and it creates packets and uses smart beaconing to send it into the ham radio APRS network via an attached ham radio.

The TT4 can do more than this, and one of the cool things about the TT4 is that it can take sensor data and attach it to these packets.

There are devices called "digipeaters" which hams set up to hear radios like mine, and retransmit them, the idea being that other radios in the area can more easily hear them. Transmissions can go over multiple hops or none at all depending on the path that the user sets in the tracker.

Furthermore, there are "i-gates" which are receivers hooked up to the Internet, which take packets (that are not flagged to not be gated) and post them to the Internet, where you can look at them on maps such as at the above links.

There are 30,000 or so APRS users out there, and a device that can include sensor data with a scheduled transmission is useful. This brings us to the other neat feature of the TT4, which is that it can be used as a data modem or "TNC" as it is known in ham radio speak.

APRS is not only used for tracking yourself (in fact, use of this mode with no other information is discouraged by some because it really does not contribute much other than a spot on a map, and does lead to more congestion of the channel.) Some other uses include letting people know how you can be contacted (as I did, by including the frequency I'd listen to), or send messages back and forth (many APRS systems are capable of messaging), or transmit weather station information, or many other uses.

What I wanted to put out there is that the SunSPOT is a device that is easily programmable using Java and has a number of interesting sensors that are of interest to hams, the original Makers. Temp sensor, accelerometer, inputs/outputs, etc. What could be done if you connect a highly programmable sensor like this to a network like APRS? What could you get from a network of sensors working simultaneously or that can receive and act on messages sent to it remotely?

Open Discussion of Developer Issues

Posted by sean_sheedy on January 17, 2008 at 04:07 AM | Permalink | Comments (0)

Over the years, there has been much written and spoken about the challenges facing mobile developers. This will be no different in some of the sessions and in the hallways at the Mobile & Embedded Developer Days conference and at BarCampME in Santa Clara next week.

To facilitate converting talk into action, a room has been been reserved from 9 AM to 1 PM on Friday January 25th near the MEDD site for an extended face-to-face discussion.

The timing coincides with the conclusion of the MEDD conference to take advantage of the momentum caused by the conference, and so that members of the community who are flying in to attend the MEDD conference can participate in this discussion.

The discussion is not limited to any particular technology or aspect of the mobile application ecosystem.

The agenda is fluid but is looking something like this:

Introductions - getting to know each other and why we are interested in developer issues
Vision/Goals - what would we like to accomplish in the interests of developers? In 2008? In the next quarter?
Recent Activity - What was attempted last year that worked or did not work?
From Talk to Action - Blogging and writing articles has helped us understand but not necessarily led to change. What new *actions* can we take during the next quarter towards reaching these goals?

We might only reach the second agenda item, but leaving with a better knowledge of who is genuinely interested in addressing mobile developer issues, having a common vision, and sharing email addresses and phone numbers, will in itself be a great first step.

If you are interested in attending, please email Terrence, or myself at developermeeting@gmail.com.

Pack your sleeping bags!

Posted by sean_sheedy on January 15, 2008 at 03:24 AM | Permalink | Comments (0)

Pack your sleeping bags! The MiniBarCamp, "BarCampME", which bridges the two days of the Mobile & Embedded Developer Days (MEDD) conference, is on!

My friend Dan Green is due a big Thank You from me and everyone who will participate, because late last week he found a secret FooCamp/BarCamp veteran who came through with the support we needed to make it happen.

The MiniBarCamp starts at 8:30 PM Wednesday January 23rd, after the MEDD dinner, and runs until 8:30 AM the next morning. Information can be found here:

BarCampME

In case you were wondering, here is the Wikipedia entry for BarCamp.

Thank you Terrence Barr and Roger Brinkley for putting this on the MEDD agenda!!!

Android's "do not fragment" clause...

Posted by sean_sheedy on November 07, 2007 at 10:59 AM | Permalink | Comments (0)

The OHA members have signed an anti-fragmentation clause. "They've basically agreed not to fragment nor do things that would result in different versions of the platform", says Rich Miner in the PC World interview. And the JCP has that too - called MSA. But as Java ME developers know very well, there are many facets to fragmentation extending beyond the platform and well into the surrounding ecosystem.

A strict "do not fragment" clause is impossible to implement without putting every aspect of the platform and ecosystem through a committee, or relinquishing creativity and possibly IP to a central authority. This is because the other face of fragmentation is called innovation and differentiation.

If many vendors are playing similar roles in the ecosystem then I don't care if there is an anti-fragmentation clause in OHA, you are going to see some fragmentation. Some of this is beneficial: you need to allow new features to appear in devices and new services to be offered. "Fragmentation management" is needed so you don't eliminate the innovative process when eliminating redundancies that appear as a result of that process.

What this clause is, however, is a huge, essential step in the right direction. It establishes a positive spirit of cooperation. It reminds competing parties why they need to be at the table. It justifies discussions on processes throughout the ecosystem, such as application certification, signing processes, distribution, rewarding the creation of new features and services, open issue tracking and sharing, collaboration on documentation and developer support, interoperability testing and "bake offs", etc.

One of my objectives in my candidacy for one of the open Java ME EC seats is to drive the EC to expand its scope to address the areas of fragmentation that go beyond the platform. Having everyone sit down and sign a "do not fragment" statement, no matter how symbolic, is perhaps a great way to set the tone for the collaboration required to do what everyone already wants: turn the symbolism in concrete practices.

On the Android announcement - a bullet list

Posted by sean_sheedy on November 06, 2007 at 10:01 AM | Permalink | Comments (2)

Android has existed for probably about 4 years, created by people who have real handset experience, so a delivery timeframe of 2H08 is not unreasonable. Google acquired Android back in August 2005 and it had already been running for 22 months by then.
This old (March 2007) article tells us perhaps more technically than most of the news about the phone that came out in the past day.
Given that article's date, and its lack of mention of a lot of other players, and the growing leaks of Gphone news in the press prior to the announcement, the other players in the announcement were probably brought on board shortly after this and probably have been working on this coming on 4-6 months...
Sun was noticeably absent but Jonathan Schwartz blogged his full support yesterday and promised full support in NetBeans. This is really great news for Java developers.
If you peruse the press releases from the companies in Open Handset Alliance you will find a little more tech info which shows that it's a Java play as far as developers are concerned and quite possibly that Linux will not be exposed to developers (or at least not to anyone but close partners.) Could be wrong about that last part, and this is what we're all dying to see in the Nov 12 release of the SDK.
This is underscored by the presence of Esmertec and Aplix who have created the Java ME platforms for a lot of mobile phones.
If you look closely at all the companies in the OHA list, and do a little dreaming, you can piece together a vision for a handset with some pretty intense and useful capabilities that will be yet another nail in the coffin of Frankenphones we have to live with today. (I'll provide my definition of Frankenphones later, but the short answer is that it is what you get when product managers are allowed to make major functional and design decisions for handsets.)
The presence of Nuance as part of the voice solution suggests that this may provide a stepping stone towards giving the VOIP industry the vision it needs to get out of its saturated but under-realized state. Personal IVRs may be right around the corner. Home phones where you have one line that rings through your whole house and you can't make a call while someone else is on the phone will be as passé and unacceptable as party lines would be (though you might see stuff like Selective Ring, since you may want all handsets in the house to ring, but need to know who in the house it is for.) OK, maybe this is stretch here, but VOIP is an industry ready for a focusing as much as applications and technologies we are discussing here have focused mobile data after its early fits in starts in the late 90s and early 2000s.
Expect to see telephony integration in the PC taken to the next step as a fallout of this.
That they cobbled together 34 companies for the OHA announcement so secretly is amazing. The NDA must have some pretty big teeth. Even people who should have been involved in this did not know about its full extent until yesterday.
Apple has proven that a sufficiently sized outsider is a gorilla in this space and will ravage the china shop if ignored.
You cannot ignore Google; they are a bigger gorilla than Apple both in market cap (about 40% greater) and arguably, penetration of their respective industries, depending on what industries you consider.
Still, there must be a pretty darn good business case for the parties involved in Google's pitch deck. I would love to see an unedited version of that.
Not to mention that those on the OHA missed the iPhone boat, so there may be a bit of fear of not being on board for this "second chance". Operators are saying that they recognize the days of closed phones are nearing the end (this is mentioned a ways down in the article by one of those interviewed.)
How open is OHA? At the end of the FAQ on the alliance on www.openhandsetalliance.org is an email for questions about joining OHA. Of course, I sent them an email asking what the process is for joining. (I already know the general answer, but why not get an official one?)
Interesting that Qualcomm is on the list, obviously because of chipset implications, but also because this directly competes with their relatively closed BREW business. What does this spell for BREW?
Also interesting, but not surprising, that AT&T is not joining, but they already have their own pet gorilla.
Nokia is also not on the list which is also not surprising as it has its own plans for a soup-to-nuts ecosystem around its handsets as evidenced by its recent location acquisitions. At last month's CTIA conference, NAVTEQ held a full day session which emphasized the many yet-unrealized possibilities surrounding location, including taking location to the pedestrian level - which is where Google will play with Android. In the Wall Street Journal, Nokia said they already have an open system in their high end phones.
PC Magazine reports that OHA members are not dropping other OSs for Android.
Additionally, there are reports that signing on to the alliance does not mean that a company will create a "google phone". This makes sense, as Google said that it did not want to build a phone - it would probably not want to deal with phones any more than it wants to deal with a Google PC - but it does need an environment that meets its needs.
So given this, and with OHA's website not really being more than a link or two deep, is OHA more than a bunch of press releases? Today, probably not. Will they eventually standardize this work, or push the standards work out to places like the JCP, W3C, OMA, IETF, 3GPP and CDG?
I also have to comment that the video on the OHA website plays like the tours of Pixar in the DVD extras of films like Toy Story. Don't all the robots look just totally cool?
Finally, a reference to the JCP. Opening a dialog with OHA should be a priority - if Android has meat (which it does by all indications) then working with them is going to be imperative.

Note that this is all written before seeing the Android SDK. However, there are a lot of smart people behind this, and with people like Jonathan Schwartz supporting it (who probably has insight into what is under the covers - I will leave the commentary on this for others), there will probably be some very interesting stuff for Java developers.

Sean

Voting is Good but Making Your Voice Heard is Better

Posted by sean_sheedy on November 01, 2007 at 03:46 PM | Permalink | Comments (2)

After spending several years in the Java ME standards circuit for a major operator, I'm now on my own as a consultant, and running for one of the open Executive Committee seats as an Individual. I'd really like to know what burning topics Java ME developers would like to see the winning candidates bring to the EC.

Java ME has been fabulously successful with well over 2 Billion devices shipped. A lot is being done right, but it does not mean that the platform is without issues. Some are longstanding, and current EC members tell me that the desire for correcting them is universal. However, the nature of corporate life makes initiating these discussions difficult. How do you tell your boss that you need travel budget to discuss fragmentation with your biggest competitors? "You're going to discuss what with who?"

An Individual can facilitate discussions on these issues. They have the advantage of not having corporate encumbrances. They are freer to start conversations among competitors to bring those to the table who need to be there for change to happen. They can highlight other Members' public actions that demonstrate their commitment to the Community Process, without being accused of "aiding the enemy." They are freer to question private actions within the EC that undermine those public actions, without burning vendor/customer relationships.

In my position statement, I listed many potential objectives, but with only 15 people in the EC, you have to focus in order to get anything done. So I am interested in hearing what people consider to be the first issue for a new EC member to raise after they are elected to the Executive Committee.

In the JCP, a Community with over 700 members, about 2/3 are Individual Members and of the remaining 1/3, a significant number are smaller companies. However, between the EC and MSA - the two bodies that drive ME - all but one member is a large corporation. This is not to say that these companies do not represent developers. From personal experience I know they do, but developer interests are represented through a corporate lens.

What do individual developers want to accomplish when that lens is removed?

A Call for "Open Enrollment" for MSA (Mobile Service Architecture) Advanced

Posted by sean_sheedy on October 24, 2007 at 04:46 AM | Permalink | Comments (1)

MSA Advanced is chartered to define the next generation Mobile Java platform. So, it seems logical to get the experience and expertise of many users and citizens and developers into the discussions surrounding this new platform.

However, there are no individual experts in MSA Advanced.

The problem is that once an Expert Group (EG) has been selected, it's common for a JSR to stop accepting participants and remain closed at the discretion of the spec leads. Somehow this EG formed without Individual experts. MSA Advanced's web page on JCP.org shows that it started in summer 2004, and was scheduled to finish a little over a year later. A lot has changed in the mobile space since then, and the individual perspective would contribute valuable insights.

There is a precedent for joining JSRs after "open enrollment" ends. Motorola's Mike Milikich, the spec lead for MIDP3, has an open-door policy for any JCP member wanting to get involved with that JSR. The result is that many eyeballs have improved the richness and quality of the specification. The "too many cooks" problem has not materialized.

In his keynote at JavaOne 2006, Jonathan Schwartz said, "This is not a heavy-weight corporate kind of environment. You go to JCP.org, you register as an individual . . . We want to make sure that all voices are heard in the process . . . This is not about corporations defining a technology platform, this is about users and citizens and developers defining that platform."

I know many of the participants in MSA Advanced. They are intelligent and kind, and they and their companies have repeatedly demonstrated how much they value the role and the input of individual developers. Furthermore, MIDP3 has shown that there is great value in the contributions of individual developers in the EG process. Maybe a little reminder of this is all that is needed for the MSA Advanced EG to announce "open enrollment" in the very near future.

How Java M&E Developer Days came about...

Posted by sean_sheedy on October 02, 2007 at 12:28 PM | Permalink | Comments (0)

Finally, everything I'd like to see in a mobile & embedded developer-focused Java conference.

It started in mid-June with this email from Roger to folks like CEO and Eric Giguere:

"Terrence and I are thinking of starting a Mobile & Embedded Conference that would occur some time in the late fall/early winter. This would be a conference solely devoted to Mobile & Embedded developers..."

Making your point on standards matters

Posted by sean_sheedy on September 18, 2007 at 01:25 PM | Permalink | Comments (1)

The MIDP3 Expert Group (JSR-271) is meeting this week, and if you have something on your mind that you want the EG to take notice of, now would be a good time to act. Feel strongly about something? Try the personal approach.

The MIDP3 spec lead, Mike Milikich, has done an outstanding job getting the individual developer's perspective by making the EG easy for individual JCP members to join. Additionally, many of the manufacturers and operators in the EG have close ties with their companies' developer and partner programs, and speak from the perspective of developer needs. Mike has actively encouraged the surfacing of developer perspectives since MIDP3 began.

Yet with all this work, developers tend to be underrepresented on MIDP3 and Java ME JSRs in general, simply because it is generally not feasible for individuals to travel around the globe to standards meetings on their own dime. Although operators and manufacturers try to speak from the developer perspective, it is not the same as representing yourself.

One way to get heard in MIDP3 is to email the EG at jsr-271-comments@jcp.org. Received just before this week's face-to-face meeting, your email will be fresh on the minds of the EG members.

But if you really want to make a point, make a personal connection with a like-minded EG member. Take a look at the list of participants on the JSR's home page at jcp.org. Google any individuals you find and shoot them an email, or better yet, dig further, find a phone number, and call them. You'd be surprised how few people actually do this. It really does make a difference and makes traveling to these meetings that much more worthwhile.

Remember that individual EG members cannot represent other individuals (and please don't share any of your IP), but we most certainly can raise points that we feel are important to the community. The personal approach is hardly used yet is one of the most effective methods for getting your voice heard.

MIDP3 EG face-to-face wraps up

Posted by sean_sheedy on June 26, 2007 at 09:12 PM | Permalink | Comments (0)

Another MIDP3 Expert Group face-to-face meeting wrapped up today. I have to say, although I went as an individual JCP member and paid my own way to Spain, it was worth every moment - the friendships, the networking, the feeling of accomplishment as we worked through spec issues, dusting off high school foreign language skills, being able to have intelligent conversations with geniuses in the mobile space... it was wonderful. There was a LOT of working going on - many people tired if not burned out from all the travel, the 9 1/2 hour days, the office email that one must attend to back at the hotel - all of this making the time after hours that much more anticipated.

Speaking of after-hours activities, unlike other standards bodies, you don't find JSR EGs running off to boondoggles in the French Riviera or Thailand - they generally meet in ordinary cities in Europe or somewhere in the US, alternating continents each meeting. Someone from the EG volunteers to host a meeting in one of their offices, pays for food to be catered, and takes folks out to dinner one night for the "EG Dinner" (which prospective EG hosts should know is NOT mandatory.)

Before and after meetings, some of us explore the city we've come to for our meetings...

Clarifying the MIDP3 pauseApp proposal

Posted by sean_sheedy on June 20, 2007 at 04:29 AM | Permalink | Comments (3)

The intent of this post is to summarize and address the developer comments regarding the MIDP3 proposal to deprecate pauseApp, and hopefully clarify some misconceptions about the proposal. I want to thank Enrique Ortiz for using his position in the industry to help get the message on this topic out to developers via his blog and post to KVM-INTEREST which is reflected in the Mobile & Embedded forums at java.net.

Mike Milikich, the MIDP3 EG lead, has asked for developer input on two specific questions:

What percentage of your applications implement pauseApp, and for the ones that do, what functionality is present in pauseApp?
For any applications that implement pauseApp, what would be the effect of running that application in an environment in which pauseApp was never called?

If you don't make it through this rather long post, these are the two most pressing questions at this point.

Also, I will be going to next week's MIDP3 face-to-face meeting. If there is a particular aspect of this topic or any other you would like me to emphasize, post a reply, or call me at +1-703-771-8527. The developer community is underrepresented in face-to-face meetings because of the substantial time and financial burden that attending these presents, and frankly we need more of the "street smarts" experience of developers.

What is driving the proposal?

The MIDP3 pauseApp proposal revolves around these points:

Message from MIDP3: Goodbye pauseApp!

Posted by sean_sheedy on June 13, 2007 at 09:13 PM | Permalink | Comments (13)

[Clarification and developer bias: The EG is providing finer grained notification functionality such as DisplayListener (see the EDR javadoc) that will move some of the platform-dependent functionality overloaded into pauseApp (and NOT defined in the MIDP specification), into platform-independent APIs whose behavior IS defined by the specification. In other words, if the capability provided by pauseApp is better provided elsewhere, isn't the natural result that can we reduce the confusion and fragmentation around pauseApp by making it a no-op (as implementations like Nokia's already do today?)

So the question to developers could be, what platform-specific stuff are developers doing with pauseApp that MIDP3 may need to accommodate if pauseApp is never called?

And if that capability is provided elsewhere, pauseApp's remaining function is to allow the environment to notify the MIDlet that the MIDlet is about to lose CPU time. Do we, as developers really implementations be able to "pause" us, to stop our threads, given that today's platforms are powerful enough to allow them to get at least some CPU time? What reasons might we want to keep the Paused state around? ]

To help reduce fragmentation, the MIDP3 expert group wishes to deprecate MIDlet.pauseApp, and wants your input - especially if you are negatively impacted. The idea is not to remove the API, but simply require that implementations never call it, and eliminate the need for developers to provide an empty pauseApp method.

There are several questions that the expert group would like the community to weigh in on. They are:

Are there any VM/platform providers who will be severely impacted by this change? That is, is pauseApp woven into their implementations so deeply, or required by the nature of their platforms, that not being able to signal a MIDlet with pauseApp would create fundamental issues?
Are there any software developers whose applications would require fundamental and expensive changes in order to run in an environment where pauseApp is never called?
Are there any other impacts the EG should consider?
Should this apply regardless of whether or not the MIDlet is designated MIDP3? That is, should platforms be permitted to provide legacy pauseApp functionality to MIDlets indicating MicroEdition-Profile less than MIDP-3.0?

I suppose we're not expecting a huge outcry of opinion on this, but if you have something to say about it or are impacted, definitely say so. You can leave a comment here and/or email the MIDP3 EG at jsr-271-comments@jcp.org. This post is rather long, so if something jumps out at you, comment on it; don't feel you need to read or understand the whole thing before doing so.

A copy of the proposed API javadoc can be found at
http://seansheedy.com/standards/midp3/pauseApp/MIDlet.html.

Powered by
Movable Type 3.01D

java.net RSS Feeds