• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)


Date: Saturday, 19 Apr 2008 06:57

It was a hard finish to the contest. I got hit with a 7 hour power outage to my apartment building on Saturday. I didn't get back into coding until 10:30 PM. On Sunday, two team mates in Europe got hit with a power outage, theirs' was a matter of 10 minutes; but they lost their work. On Monday, I saw another teammate, Gurv – a seriously fast coder – go black at 3:30PM. We submitted at 11:50PM, ten minutes before the deadline; Gurv came back online at 11:53PM, his Internet connection had gone down for over 8 hours. Still we pushed through with most of the features and everyone was happy with the result. We managed to pull off a really cool animation of the main menu system in those last few minutes. None of us was willing to give up on it, even if it risked the deadline. Kon, our UI guy, really pulled some magic on that one.

On Monday morning, George was also frantically, trying to set up a company at the last minute, which frankly I thought was impossible to do in six hours. He'd already maxed his credit cards getting all the servers up, paying for svn, bug tracking, and a whole host of other stuff we needed but he managed to dig up the last of his money to transfer to pay the fees for setting up the company. He pulled it off and I guess he may be homeless soon. But with wifi and a computer, he will be ok.

Tuesday, I had to get up and do taxes. I was wasted and didn't really want to do them and ended up wasting a lot of time. I made a major typing mistake; I caught it on a review. I e-filed it but had to go to the post office to mail my estimated taxes for next year and there was a line of cars to even get into the parking lot. It was one of those days.

Wednesday, I started back into a normal routine but still exhausted. I had a lot of patches piled up for NMaven, so I started reviewing those and then started digging into some Sonatype specific work in the afternoon. Sonatype is a cool company and didn't have any problems with me taking off nearly three weeks to jam on JVending and the SlideME launch. All those guys live and breathe open source.

Thursday, started to feel normal, took my kid to soccer and watched her school stage performance in the evening. Humanity started to seep into the bones again.

Now, I see all the traffic on the android challenge lists. This list is the most neurotic mailing list I have ever belonged to: people anxiously wondering how many submissions there are, cranking out useless calculations of odds, worrying about when the judging starts, worrying if they will be disqualified. If it weren't for critical pieces of information showing up there, I'd be perfectly happy to unsubscribe completely. Me, I could care less about the results of the contest. We did a damn fine job, and we have all sorts of plans in the works. We will be launching our full client in a few weeks. The big plus of winning the contest would be having a little extra cash to keep George off the streets, which would certainly be something.

Doing an assessment over the last few weeks, the results are mixed. We had a successful launch of SlideME.  We successfully proved the flow from stocking of content, to discovery on the emulator, to download and install of Android applications. We worked out a ton of issues, but still have a ways to go.

On the negative side, we only picked up six content submissions to out content server. Our site is hands downs the best out there for content submission and discovery but we can't seem to get the traction with the community. HelloAndroid, which can't compare to what we have in content discovery, picked up a huge number of people submitting their apps to the forums on the 14th.

Talking with some developers, they seem to think we are about browsing for applications, which is completely wrong. We are about content stocking AND discovery AND delivery. We are about advertisement of developers. Stuffing a description and apk file on a forum won't allow you to deliver it to a device, it won't allow you to discover it on a device, it won't allow you to bill for it. At SlideMe, we are building the infrastructure for this and are open-sourcing a lot of what we are doing to benefit the entire community. We are busy preparing for the launch of devices at the end of the year, so that small developers have a way to get applications to the end user.

If you are interested in joining the community, submit your application (apk optional) here: http://slideme.org

Author: "Shane Isbell" Tags: "Java"
Send by mail Print  Save  Delicious 
Date: Thursday, 10 Apr 2008 07:45

We finally got the SlideME Portal out the door. You can find a full announcement here.  It was a tough, exhausting launch and felt like the old days when I used to work at T-Mobile. We had four people, including myself, working around the clock during the week. I'd be collapsing at 6AM and while the other developers would already be online in Europe, and vice-versa; so we had constant momentum.  There were a lot of moving components:  Drupal on the front-end web, feeding into JVending on the back end and then JV feeding into the client. We would find some catalog information on the Android client that didn't exist in the Drupal CMS, so we would need to manage that from CMS to JV, back to the client. JVending is pretty mature and held up well, not requiring many changes; I had already added the OMA OTA adapter for Android content delivery a few months back.

Getting the layouts for the application manager was also challenging. There were a lot of screen shots going back and forth and discussion about the capabilities of what we could and could not do in Android. I implemented three different interfaces over the course of the client. Fortunately, the UI framework for Android is pretty easy and we had one experienced UI engineer strictly dedicated to the UI design for the site and the client. That's one reason the L&F is pretty consistent between the two. It does amaze me how these guys can recognize certain pixels being off. Honestly, I just can't see it, I'm tone-deaf and they have perfect pitch.

We had an early commitment to go open-source with the core components. In some ways this is an advantage, we can talk about what we are doing on the lists and get feedback. We can also leverage public infrastructure like code.google for mailing lists, svn and so forth. This takes mere minutes. But it also meant that we needed to do public releases and documentation of multiple projects. We needed to apply licenses, javadocs, think about how users could leverage the API. And of course, there is always that gnawing feeling that you are giving away too much, that someone else is going to take it, use it against you and put you under. But then the fun of it sinks in and – well, that’s enough, the fun of sharing and of being able to talk about what excites you. 

In our case, we had to do two JVending releases and a SlideME client release before we could go live with the site. It's here that I really appreciated Apache Maven, being able to cut a release fairly quickly. Then I found myself improving the Masa (Maven plugins for Android) as I tried to make my own life easier, like adding on a provisioning archive packager to submit Android applications to the CMS/JV system. Needless to say, if you build Android apps with Apache Maven, doing releases and getting them out to the devices and in the hands of users is going to be a piece of cake.

But with three code.google projects going on at the same time, I began watching IDEA pull 500MB of memory. With all the emulators, apache tomcat, debuggers, etc, I was at 2.5GB and into virtualization. The speed was infuriating at times, but I couldn't shut anything down, too many components.

But my favorite part of the project was finding out over the weekend that my old code that handled package installation on the old Android SDK no longer worked. Google considers this functionality as unstable; after poking around, it looks as though Google engineers are still thinking about the security implications of installing packages and haven't yet gotten around to how to allow other applications to use this functionality, only how to block them. So I am sitting there over the weekend with an application that has to install other applications, in fact that is the whole point of the application, only to find that the latest SDK doesn't work. So plan B: I built a simple external service that could relay the download and install requests without being subject to Android's control. This only took a few hours to complete, but still it’s the last thing you want to be doing at the last minute. Once Google gets the application installer issues worked out, we can swap this content handler.

My second favorite part of the last week was having my firewall hacked. I first noticed attacks against Norton, which meant they were getting through the hardware one. My computer then froze and blue-screened. And then on rebooting, none of my Android code worked. The app was just freezing on catalog downloads.I checked my firewall and noticed five allowed MAC addresses; I only have two computers, so that wasn’t right. And then I noticed that my port mapping from my public IP to my internal IP was no longer mapped (the reason Android froze). Later I found I couldn’t log in to the remote computers hosting JV, using RDC, so after a quick packet sniff, I noticed that the ports were no longer open, so I fixed that. Lots of fun, I assure you.

Throughout this whole ordeal, there was a lot of determination to be the first out there. I don't know why but this is often an important motivation, bragging rights I suppose or perhaps not wanting to be a "me too" or follower. And sure enough a few hours after we announced, HelloAndroid.com announced they would be soon entering the same space providing services similar to ours.  But we aren’t standing still, we have some other things in the work, so while they are catching up, we will – well, that you will find out later. In some ways, all this competition around an SDK and emulator is humorous. I've never seen anything like it but I think it goes to show that there is a belief in Android. 

Just noticed that someone submitted an Android  application to SlideME and the SAM client broke. Sigh. Back to work getting this fixed, so I'll end here. And then back to Maven and NMaven projects, which will turn into my primary focus soon. Lots of cool stuff coming out of Sonatype these days. Too much to do. 

Author: "Shane Isbell" Tags: "Java"
Send by mail Print  Save  Delicious 
Date: Friday, 04 Apr 2008 22:13

I just released JVending 2.0, which includes support for stocking and delivery of Android content. This is the first non-alpha release, as JV seems stable enough in a real environment and most of the bugs have been worked out. I also moved it from the old sourceforge site to JVending.

After three years of largely going it alone, in August 07, I had finally decided to throw in the towel on JV and spend my time on other open-source projects that had more momentum. And then Android came out in November. I liked the platform and saw a lot of developer interest. And the mobile community expanded overnight, although many seemed to think that the doors had opened to them, that somehow they were being held back because the existing technology was not open-source; which of course, is not true. It’s the ecosystem that is flawed.

JV came out after the J2ME market had already matured and getting a sizable community run portal for mobile content was lost. But when Android came out, I knew there was a shot again. Nobody had built the infrastructure yet. There is always an awareness that large companies can leverage their existing assets to move in quickly (this is what we did with JV). It’s about getting some technology out there that works and quickly building a community around it. From a technology perspective, the small developer is always going to get squashed by the big players, so you can’t rely on technology alone.

When working on JV, I have always kept Jason Briggs “Leveling the Playing Field” JDJ 2002 article in the back of my mind. It was an article with a lot of foresight; but rather than forming such communities, small developers just stood there and let themselves get run over. So I can’t completely blame the carriers or other mobile players for the situation; dealing with thousands of developers is a pain. The sad fact is that small mobile developers have never gotten their act together. I even see it in the Android forum lists today. XYZ developer has a super duper game app and doesn’t want anyone to know about it (in case someone steals the idea), so they sit on it, with the intention of directly approaching a game aggregator or a carrier. They are now into the existing ecosystem and that hasn’t changed. One guy even claimed that putting your app out there for others to test would cheapen the image of the application. These sorts of attitudes will doom the power of any developer community. Developers are isolated and picked off, one-by-one.

With JVending and the new community portal (more on that next week), I hope that we small developers won’t follow the same path as we did with J2ME. It’s worth a shot not to.

Author: "Shane Isbell" Tags: "J2ME"
Send by mail Print  Save  Delicious 
Date: Wednesday, 02 Apr 2008 16:44

I just opened a google code project: Masa, which handles the building, packaging and installing of Android applications to the emulator. I have also added support for aidl generation, as well as PAR (provisioning) packaging for a JVending server.

This code had been sitting around for a while in the Maven sandbox; I wanted to get a project site setup for releases, documentation and so forth, so I moved it.

I also created an m2-repo project for hosting of various artifacts, including masa. You can add the following to your pom or settings file to grab the artifacts.

    <repositories>
        <repository>
            <id>m2-repo.release</id>
            <name>Maven Release Repository</name>
            <url>http://m2-repo.googlecode.com/svn/release</url>
            <snapshots>
                <enabled>false</enabled>
            </snapshots>
            <releases>
                <enabled>true</enabled>
            </releases>
        </repository>
    </repositories>

A pom would look something like:

<project>
   <modelVersion>4.0.0</modelVersion>
   <groupId>org.jvending.masa</groupId>
   <artifactId>maven-test</artifactId>
   <version>1.0.1-sandbox</version>
   <packaging>android:apk</packaging>
   <name>maven-test</name>
   <dependencies>
      <dependency>
         <groupId>android</groupId>
         <artifactId>android</artifactId>
         <version>m5-rc15</version>
      </dependency>
   </dependencies>
   <build>
      <sourceDirectory>src</sourceDirectory>
      <plugins>
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
               <source>1.5</source>
               <target>1.5</target>
            </configuration>
         </plugin>
         <plugin>
            <groupId>org.jvending.masa.plugins</groupId>
            <artifactId>maven-dx-plugin</artifactId>
            <extensions>true</extensions>
         </plugin>
      </plugins>
   </build>
</project>

For the curious, the name Masa comes from PKD's book We Can Build You. In the book, there is a company MASA Associates (Multiplex Acoustical System of America), which was responsible for building simulacra (or androids).

Author: "Shane Isbell" Tags: "Java, android, maven"
Send by mail Print  Save  Delicious 
Date: Tuesday, 25 Mar 2008 02:14

The Apache NMaven team is pleased to announce the release of NMaven 0.15-incubating.

NMaven provides Maven 2.x plugins to support building of .NET applications.

http://incubator.apache.org/nmaven/0.15/

Features for this release include:

  1. Compiling C# projects (2.0 framework)
  2. Strong Naming
  3. Generation of assembly info based on pom metadata
  4. Support for Microsoft and Novell/Mono platforms

-- The Apache NMaven Team

Author: "Shane Isbell" Tags: ".NET, .net, maven, nmaven"
Send by mail Print  Save  Delicious 
Date: Saturday, 12 Jan 2008 00:45

Exist acquiring DevZuz actually happened a while back but it just became public.

On a Thursday in mid-November, I received a message from the CEO about some important meeting on Friday, which turned out to be the last day for most of the developers, including myself. It struck me as odd for Exist to acquire a company based on open-source and then lay off most of the developers with connections into the various open-source communities. Continuum and Archiva probably took the biggest hit; their dev list traffic took a nosedive, along with commits. And yet these products are (were) part of DevZuz's critical infrastructure offering.

It was a bit of an odd time for the Apache NMaven podling, which never had a critical place in the offering. NMaven had taken 9 months of building prototypes and working out some really nasty issues with Visual Studio integration. We had just verified with a customer that they could successfully use it. And then poof, a week later, all for naught.

The VS integration had caused a fairly big divergence between NMaven and Maven, which I never was happy with. Without the VS constraints, I started looking at how to simplify NMaven and bring it back in line. Then I got a call from Jason and soon accepted an offer with his company: Sonatype. The alignment is good for NMaven: dev list traffic is rapidly increasing and there is more committer participation; it also looks promising that we will have our first NMaven release within the next week or two.

Author: "Shane Isbell" Tags: "General"
Send by mail Print  Save  Delicious 
Date: Friday, 04 Jan 2008 02:56
After nearly two months of Google drumming up support for the Android contest, and getting various teams excited, they have released the terms and conditions. Section f: "Google will award the Qualifying Grant to the one (1) member of the team or Business Entity" Personally, I think that this is going to get messy, not for Google, but rather for the development teams and will likely collapse many teams. First, if you have been following the android discussion lists, you will have noticed that a lot of teams have sprung up where the developers don’t know each other. Keeping in mind that many teams are in it for the prize money, would it be reasonable to assume that they trust the designated “member of the team” to pay them anything? Particularly the “idea” people, who assemble the teams, don’t do any work but will be the one’s receiving the grant. I would think anyone submitting an application should be able to tell Google to pay dev1 x amount, dev2 y amount and so on but this is not the case. The second problem is the tax mess awaiting developers scattered across the globe, all with different tax rates and laws. Rather than Google paying each team member directly, they require the designated “member of the team” to deal with it. Unless the team members are clever in regards to tax and business laws (not clever in a fraudulent way, which I suspect will also occur), there will be double taxation, since the recipient is required to pay other team members. Overall, this is a bad deal for development teams that intend to compensate the developers for their work. These problems could have simply been avoided by paying each developer directly, as specified in the application form.
Author: "Shane Isbell" Tags: "Java, android"
Send by mail Print  Save  Delicious 
Date: Sunday, 09 Dec 2007 23:17

It's been nearly a month since I left DevZuz. I have been busy and there are a lot of changes on the projects I have been working on.

First, the direction of the Apache NMaven podling has changed. A lot of the DevZuz work dealt with getting the Visual Studio addin working with Apache Maven .NET support. Most of this project is done, but I'll be pushing out things like Maven VS2005 VB.NET support to a future date. The latest focus is on getting NMaven more tightly integrated with Maven. We've got a branch out there and it contains a cleaner, but still incomplete implementation, that will integrate better with Maven: there is no longer any capability/requirement matching, we've discontinued use of the config registry (now using annotations) and of RDF. We've also left out the functionality for writing Maven plugins in C#. Mono has a bug and doesn't support the use of custom application domain managers. Novell will likely not be adding support anytime in the near future, so the current implementation only works on Microsoft. I'm hoping to dig into this matter with the Microsoft guys at the compatibility labs session sometime next month. There may be some cleaner solution that doesn't involve loading up the plugins with new domain managers.

I've also reopened my JVending project. I closed it down in August, I just didn't have the time with everything else going on. Now I'm working on adding SOAP interface support to the catalog and once that's complete, I'll do an 2.0.0-alpha5 release. One reason I reopened the project is that I'm hoping to leverage JVending for an android community application/service. I posted details of this on the android discuss list, it was no surprise that no one in the community responded. Fortunately, I have found a couple of other devs with the same vision, so we are moving forward to deliver a community application for provisioning and delivery of android applications. I am also working on a client SDK, I'll likely get the first code import within the next week as well. I think once all the pieces are in place, there will be some community interest, and if so, we'll be submitting parts of this for the Google android contest next year. More details on the SlideME community site within the next month or two.

In regards to Byldan, I just uploaded the latest code and expect to get out a 0.5 release within the next day or so. This supports cyclical dependency detection, much better build output and additional build task types. There are also projects in there for resolving and downloading assemblies, but this is still incomplete. I'll provide a functional version in byldan-0.6+.

I also had time to dust off my Garmin GPS and get it working in the Android SDK. I had worked in the area for palm and MIDP devices ages ago, so I just wanted to see if I could do it. I'm going to try to find time to open-source this, but given that I am not using it for anything, it sits on the back burner for now.

Outside of these projects and family time, I'm also doing more fiction writing, usually after 10 PM, in addition to my daily journal. Since September, I've done all of my writing with pen and paper. Editing is a pain, but my writing flows more naturally. And I just couldn't tolerate any more "screen time". Some people have asked me how I have time to work on so many things. I remember a decade ago, asking one of my professors the same thing about his own schedule and his answer was: "It's amazing how much time you have when you don't watch TV." It's true.

Author: "Shane Isbell" Tags: "Java"
Send by mail Print  Save  Delicious 
Date: Friday, 30 Nov 2007 21:51

After Google released the Android SDK, I have been trying to digest the information, which has created varying experiences, anywhere from a sweet taste in my mouth to a souring within my stomach, sometimes even verging on virtual regurgitation of information that I thought that I had properly processed. So here is my partially, but mostly digested take:

  1. Google releasing Android SDK 1+ years before the device: This creates goodwill in the community. It shows that Google is interested in developer feedback and allows the developer get their wish list in for the SDK and API well before any device ships. It also demonstrates that Google is not just targeting a select (insider), professional group of embedded developers (Apple's strategy), again creating a healthy feeling of openness. There is a bad side to this strategy, however. Since the public does not know the capabilities of the target Android platform, a lot of developers are going to build and port applications that will never be able to run on Android. This results in creating a lot of wasted, community effort.
  2. Android is not going to have much affect on the Java ME (MIDP) market. MIDP is still targeted to limited devices and Android applications are likely to be a hog on resources. Android is, however, in direct competition with the upper end Java ME, CDC/Foundation profile devices.
  3. Google's decision to give 10 million in prizes was not a good one from an open-source community perspective. This drew in too many developers who have no interest in open source, the openness of the platform or even mobile applications. It also dumbed down the developer's lists with people who clearly can't program asking programming questions. Having a small, targeted group of people, who can share and exchange information, would have made it a more comfortable place for existing mobile developers. Perhaps letting the community develop first, before drawing in the hoards looking for plunder, would have been more prudent decision.
  4. Related to above, there are too many developers, with no experience in mobile development or in dealing with carriers and in some cases with no experience in Java at all, who are telling us what is wrong with Java ME. This gets annoying. The problems have never been with the technology (just do a comparison between CDC/Foundation profile and Android) but rather the problem lies with the entire ecosystem and the openness of carriers.
  5. Android opening up the carrier market: Google has presented a neat platform but has done nothing to indicate how Android is going to change the ecosystem.
  6. Fragmentation: the only way that Android is not going to fragment the market is if it gains most of the market share or if it gains no market share.
  7. Carriers are not evil (well most aren't). Keep in mind they are hardware guys, not software. So they can be hardheaded at times and protective of their networks, as well they should be, as they have out paid out a lot of money to build out their networks. Does it make sense that they have paid multi-billions of dollars for a network that Google and others sweep in to make money off of, without themselves getting a cut? But being hardware guys, they are not experts in monetizing data services and have little experience in the advertising market.
  8. In the long-term, Android means very little to the individual, professional developer. A lot of the current excitement about Android appears to be from this very developer. I know it was (at one time) Sun's vision that carriers would target the individual developer, allowing them to upload games/applications to the network for discovery and purchase by the customer. They pitched this idea heavily when I was at T-Mobile. This didn't materialize. I think the initial resistance to this idea was ignorance, but there are some practical reasons why the decision persisted. The certification and testing of the application (almost always a game) was time consuming and costly. This was eventually pushed off to the content aggregators (although there still is internal, carrier testing). If someone downloads an application that doesn't work, a call goes to customer service, which costs the company, say 40 bucks. Get one bad game out there and you stand to lose a chunk of change, not to mention faith of the customer. Companies such as T-Mobile USA allow downloading of apps from third parties, like Moviso, which doesn't generate such costs, or revenue. This was a balance that carriers like Verizon Wireless did not strike.

    The problem, as I see it, is that Google has presented no strategy for getting the individual developer's application to the device so that the individual developer can make money. So based on the available information, Google doesn't have a strategy to sustain interest from the individual, professional developer who will go off and do different things if he or she can't make enough money. The hobbyist is another story but these hobbyists are going to be a fairly small group (as opposed to hobbyist web developers), as they will require an Android device, mobile data access, etc to maintain their interests.

  9. In these early stages, there will be some individual developers (or groups) who will hit the jackpot with the prize money; or if Android is successful, some may even have their product picked up and used to their own financial advantage. But this is a very, very small group; and if there are those who think that the current mobile industry is closed, they have no good reason to assume that the big players won't dominate and push out the individual developer after a short period of time (2 years in Java ME time). Indeed, this competition is most likely already there. Again we are back to not having a fundamental change in the ecosystem. Throwing out a marginally better platform won’t help these developers.
  10. What does Android mean to the CDC embedded developer? Good and bad. One of the problems when building a device is lining up all of the drivers and libraries, with usable licensing. This can be extremely time consuming. Android promises to solve some of these problems. There is a GUI with event handling, standard logging, APIs for the media device. So for a company that can't afford to shove out a lot of money and resources, Android will give them a head start, provided they are only targeting Android devices. If Android fragments the market (Android's success would guarantee it), it would create a big headache for those developers that have to port the applications between platforms. Still, Android would be a very good R&D; platform to work off of.
  11. What does Android mean to the MIDP developer? Nothing, if they needed more application capability, they would be targeting CDC/Foundation anyway. This is of course, not entirely true. If Android lowers the barrier of entrance to developing more powerful applications (from a technical and tooling perspective), more MIDP developers may move over.

To sum up, we have a neat platform, a crowded and polluted community, and no Google strategy to justify the current excitement that the ecosystem is going to change in any fundamental way. While I truly do like Android as a platform and will likely be a hobbyist for some time, part of the reason I highlight these negatives is that we saw a lot of the same excitement, albeit from a smaller group of people, when Java ME started on the scene back in 2001; and this excitement didn't hold up to the reality that big players began to dominate the market, content aggregators arose and J2ME development jobs flowed to overseas development shops, leaving many J2ME developers twiddling their thumbs and moving off to other work.

Author: "Shane Isbell" Tags: "Java, android"
Send by mail Print  Save  Delicious 
Date: Tuesday, 27 Nov 2007 10:27

Largely as a Sunday afternoon project, I have been working on an experimental Mavenish build system, Byldan written in C#. It doesn't have all the features of the Apache NMaven podling, but it does the basics (compiling, NUnit, FxCop) and is much faster than NMaven. The latest version in the trunk also uses sorted topological graphs, which allows for things like cyclical dependency detection.

I'm still working on the resolving and deploying features. The way this will work is that an archive containing all of the assemblies will be deployed and stocked on a server, this will alleviate the problem of multiple network trips for deploying a project. The client will then ask the artifact server for the first level dependencies, which the server will package as an archive and deliver to the client. Next, the client asks for the second level of unresolved dependencies, and so on.

I also added some things that I "wished" that I had in Maven, like being able to add plugins to the lifecycle that can execute before or after the entire build (no per module execution). This is where the directed graphs come in handy, allowing these pre/post build plugins to take the results of the global build and do things like creating one large archive, or doing a global FxCop analysis on the assemblies.

For the artifact server, I decided to try out Linq to SQL, which is Microsoft's O/R mapping framework, that comes in 3.5 (still in beta). So far I'm happy with Linq. It has easy to use annotations for setting up the mapping, autogeneration of tables and columns and other goodies.

Author: "Shane Isbell" Tags: ".NET"
Send by mail Print  Save  Delicious 
Date: Sunday, 25 Nov 2007 22:11

The mobile community used to be a small, quiet community. There would of course be the occasional outburst from an 800-pound gorilla, who would charge out into the street and beat its chest. Sometimes this would cause other 800-pound gorillas to come out and they could all be seen beating their chests for months on end, doing little else. But eventually they would all get tired and march back home, leaving the community to get back to business. Now Google has knocked down the walls of this little community and is letting in a mob of pygmy marmosets, who are now parading around the streets yelling, some climbing to roof tops and preaching that they know what was wrong with J2ME and that armed with the Android SDK, they will deliver the industry from its woes. I wonder when, or even if, these pygmy saviors will leave. Perhaps it will occur when they realize that Android is only able to maintain the ideals of their faith because it has not yet burst onto the device and wiggled its way onto a carrier network. And if this transmogrification of Android never happens, will the pygmy saviors ever leave - from boredom, perhaps?

Author: "Shane Isbell" Tags: "Java"
Send by mail Print  Save  Delicious 
Date: Thursday, 22 Nov 2007 02:22

Carl R. is excited about Android but confusing a puff of air with a -- tornado? To put some of the Android fragmentation issue in perspective: I've yet to locate Google talking about Android preventing fragmentation. The direct Google announcements that I've read have stated that they think that an open platform will help to drive innovation and collaboration, resulting in better mobile apps. That's a reasonable belief and most people in open-source won't argue with that point.

So where did this whole fragmentation issue come from? Clearly, people are concerned that Android may further fragment the market, but then there is this counteracting force that claims that Android will prevent fragmentation itself. In their minds, a dim light of realization starts to shine, hazy at first, a growing excitement, Eureka! "If everybody uses Android, there will be no fragmentation!" Could anything be more obvious? If everybody uses Windows Mobile, there would be no fragmentation. If everybody uses Fedora, there would be no fragmentation of Linux. If, If, If...

Why is the market so fragmented now? Some are pointing upwards into the seemingly bright light: "It's the Sun's fault with its J2ME specifications and the numerous industry mobile JSRs." They turn. The Googles are riding up behind them, the sun glinting off their armor, promising to unify the rabble. "Charge!" the Googles yell. The rabble runs forward into the cannon fire. Wavering, a second dim realization occurs: "If we all have the same device, there will be no fragmentation!" Perhaps because of all the smoke around them, or just the general excitement of battle, there is little realization that not all devices are created equal. Charging forward again! The remaining Android rabble are left looking around for all the billions of devices that they were promised, or rather that they promised themselves (The Googles wisely remain silent and unmoving, behind them). Gasp. "You mean that my application will only run on an Android device?" the rabble asks in unison, "Not everyone wants to shell out extra cash for bluetooth, or for a camera phone, or for MMS capabilities? But, but, but..." The Carriers loom in the distance. One of the androids sinks stiffly to its knees and raises its arms, pausing as it looks upwards at the bright light in understanding. The great rout begins.

Author: "Shane Isbell" Tags: "Java, android"
Send by mail Print  Save  Delicious 
Date: Friday, 16 Nov 2007 05:25

I couldn't find the specs for the Dex class structure, so I have been poking around. I am blogging about what I have found as a starting point for other people to start their own investigation, this is no replacement for an actual spec from Google, it is still incomplete and parts may be inaccurate.

The dex class structure is remarkably similar to the Java class structure but with some notable differences:

  1. Dex classes use little-endian encoding, while Java classes use big-endian encoding.
  2. An Android package contains one large dex class. Note that the field_id and the method_id reference a class_index so there are multiple Java class references within the dex class (although they are no longer true Java classes).
  3. Dex classes make strong use of offsets, while Java makes use of tags.
  4. It appears that the single dex class is significantly smaller than the total size of the Java classes: 1800 bytes versus 2500 bytes in one case. This would certainly help to decrease download time for apps, a good thing for wireless devices.

The class structure is as follows:

DexClassFile
{
 8 magic
 24 ? (it looks as though these aren't used for anything but they aren't null)
 4 file_size (of the dex file)
 1 ?
 8 nulls

 [The following are roughly equivalent to the constant pool in Java. Notice the absolute offsets as opposed to tags.]
 4 string_size
 4 absolute_offset
 4 object_count

 4 class_id_size
 4 absolute_offset

 4 field_id_size
 4 absolute_offset

 4 method_id_size
 4 absolute_offset

 4 class_definition_size
 4 absolute_offset
 
 [back to class information for multiple classes]
 4 class_def_index
 4 access_flags
 4 super_index
 4 absolute_offset
 4 static_fields_offset
 4 instance_fields_offset
 4 direct_methods_offset
 4 virtual_methods_offset
 
 string_id[string_size]
 class_id[class_id_size]
 field_id[field_id_size]
 method_ids[method_id_size]
 class_def[class_def_size]
  
 [Still investigating these]
  word_data
  code
  string_data  
}

string_id {
 4 absolute_offset
 4 size
}

class_id {
 4 index
}

field_id {
 4 class_index
 4 name_index
 4 descriptor_index
}

method_id {
 4 class_index
 4 name_index
 4 descriptor_index
}

class_def {
 4 index
 4 access_flags
 4 super_index
 4 absolute_offset
}

The way the string entry works (see below) is that the string_size gives the number of strings of things like methods names, classnames, etc. If also gives the absolute_offset of the string_ids, which in turn gives the absolute_offset of the string values and their lengths. The class id, field id, method id, class definition function in a similar way, giving the count of their respective structures; you can then read the structure starting at that offset.

If anyone has any other information on dex structure, let me know. I'm eager to find out how the op codes work.

Author: "Shane Isbell" Tags: "General"
Send by mail Print  Save  Delicious 
Date: Wednesday, 14 Nov 2007 10:53

When I generated my android project directory, using the SDK tools, I saw an ugly ant build.xml file. This really annoyed me, so I threw together some Maven plugins for android and checked them in here:

Maven Android Plugins

These plugins will generate the dex files, the apk packaging and then install them into the emulator. Enough fun, now back to real work.

Author: "Shane Isbell" Tags: "Java"
Send by mail Print  Save  Delicious 
Date: Wednesday, 14 Nov 2007 01:12

Well, I not an eclipse user, so I decided to create some quick Maven plugins to generate the dex byte-code and then a plugin for the packager. This fairly straightforward as I had the ant build.xml script to go from. Just to note that the error messages returned from generating and running incorrect commands is just a display of the help command output, listing the switches and options. Thus using the commandline is not going to be a terribly fun experience.

After doing all of the basic plugins, I used the adb install command, started my emulator and then watched the red cylon eye of death: a red dot streamed back and forth across the emulator screen, where before I saw I nice landscape in the background. After multiple restarts, I still see the red eye staring at me. It was pretty scary so I stuffed the android in the garbage. Maybe the next version will be better.

Author: "Shane Isbell" Tags: "Java"
Send by mail Print  Save  Delicious 
Date: Tuesday, 13 Nov 2007 21:34

I wanted to withhold judgement until I tried building with Android. I ran into a minor but annoying issue but very early on.

First I generated a sample project

    activityCreator --out sample-project --ide intellij a.b.test1 

and everything worked correctly for generating the intellij project files. The class file looks something like:

import android.app.Activity;
import android.os.Bundle;

public class test1 extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle icicle) {
        super.onCreate(icicle);
        setContentView(R.layout.main);
    }
}

The first problem is that the test1 class is missing the statement "import android.R;". After adding that I find that the R.layout.main field doesn't exist, so I go around looking for how to create a View. I try

    this.createView(...)

but that turns out to just be a stub that returns null.

I think about trying to instantiate directly, but

    View(Context context)

requires a context. The two implementing classes of Context don't work because I already need a context.

ApplicationContext(ApplicationContext context)
ContextWrapper(Context base)

Now I dig a little more and find that the Activity class extends the ApplicationContext, so I can replace the setContentView with

    setContentView(new View(this));

and it compiles. Then, after writing all of the above, I look at the Hello Android Project pages and find something similar, where they say to change setContentView(R.layout.main) to

        TextView tv = new TextView(this);
        tv.setText("Hello, Android");
        setContentView(tv);

Non compilable archetypes? Ah, the intricacies of the Google mind.

Author: "Shane Isbell" Tags: "Java, android"
Send by mail Print  Save  Delicious 
Date: Tuesday, 16 Oct 2007 20:13

I just released the latest version of Archivist, which adds support for the creation of tar files and gzip compression/decompression: Archivist 0.2. This means that all the basics are there, and now I can finally start using it in packaging of my other .NET projects.

Author: "Shane Isbell" Tags: ".NET"
Send by mail Print  Save  Delicious 
Date: Tuesday, 02 Oct 2007 17:21

I recently visited Microsoft's open-source software site. Since Microsoft has several initiatives dealing with open-source - Shared Source Access, CodePlex and Port25 - it looks as though the site is designed to be a portal to these various groups. It is not a techie site like port25, but rather more about strategy and marketing. Microsoft says that their strategy is to participate, partner, grow and learn. My first reaction was that sounded like Microsoft's old product strategy of embrace (participate/partner), extend (grow) and extinguish (learn - No! Wait! This part is different).

Under the "Grow" section, the site discusses economic opportunities, not community growth. The growth category is divided into 1) a C# based OSS project that offers support services (Deki Wiki); 2) a company that provides support services for various open-source projects (SpikeIgnited: these are all Java/PHP OSS running on Windows); 3) open-source companies wanting to enter traditional ISV arraignments with Microsoft; 4) An enterprise company that offers its software as open-source but charges for services.

We can see that (1), (2), and (4) are all about service support, while (3) deals with paying money to utilize Microsoft's business connections and network so is doubtful to be of interest to most OSS developers. (1)-(4) are surprisingly limited, and a somewhat dated, view of open-source economic models; my guess is that Microsoft is struggling a bit on this one.

Under the "Learning" section, the site talks about community. It starts with Microsoft's Ajax Control Toolkit and it's open-source model of development. If we dig a little more deeply, we will find that this project does accept patches but only for bugs, not features: this is primarily a user-driven open-source model, not a developer-driven one. This puts the MS model more in line with Sun's previous (and recently abandoned) model for OSS development; and of course, Microsoft is not releasing code for their core framework, so it is also a much more a modest one at that. This also means that since all the developers who know the code are Microsoft employees, such OSS projects can be shut down, leaving a whole group of users in a potentially difficult situation.

This section also talks about R&D; efforts to understand human computer interaction in open-source projects. Of interest: John Carroll (Ph.D. Penn State) - "For example, how might we translate some of the design and management lessons learned in the commercial arena into the community-based-software development paradigm of open source." In the FAQ section, the site states the following about Microsoft's strategy: "In addition, it includes increasing opportunities for developers to learn and create by combining community-oriented open source with traditional commercial approaches to software development." Here we see a couple of examples of Microsoft's interests in applying and blending traditional software development with open-source development. The site also puts some emphasis on collaboration (through various examples), so we start to see some underlying focus of Microsoft's strategy here: extend their traditional model in such a way that open-source developers, with a highly distributed collaboration model, will embrace it. If you have developers building applications on top of your platform, then companies will buy your operating system, databases, clustering technologies and so on. The blending of models, as well as the focus on human usability in open-source, may not be a bad thing for open-source either, provided that Microsoft's embrace-extend strategy doesn't follow historical patterns.

For open-source developers wanting practical information, I'll save you the trouble of browsing the entire site. The two interesting links are:

* Resources for Developers and Project Maintainers
* FAQ
Author: "Shane Isbell" Tags: ".NET"
Send by mail Print  Save  Delicious 
Date: Monday, 01 Oct 2007 17:15

The standard .NET APIs don't cover archives and/or compression formats like tar, pkzip or even Microsoft's own CAB file format (gzip compression being the only exception). I researched for existing open-source projects in this area but only found SharpZipLib, which is GPLv2: I can't distribute it with the Apache NMaven podling. I also found some commercial applications. I can't understand why someone would want to sell, much less buy, a library for archiving with these standard formats.

I did some work this weekend to get a basic version that handles tar files. Yesterday, I started a project on codeplex called Archivist to host it. I did consider calling it Archiva, but I don't think Joakim would find it all that amusing. The first version of Archivist handles reading and extracting of tar files. There are a number of limitations, but I went ahead and released because I thought that others might benefit. The code is covered under the MIT License.

Author: "Shane Isbell" Tags: ".NET"
Send by mail Print  Save  Delicious 
Date: Saturday, 15 Sep 2007 17:04
Long blog on Port 25's generous donation of 75 Visual Studio Team Edition MSDN subscriptions to the ASF wiped out by jroller.com. Note to self: don't hit the "Save As Draft" button for long posts. Copy and paste to notepad.
Author: "Shane Isbell" Tags: "General"
Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader