12 Nov

Enabling Voice Communication on Android Apps

Check out the new guest post that I wrote on Enabling Voice Communication on Android Apps, for the Safari Books Online blog. It covers how to enable voice communication using the Android SIP Stack/API.

Enabling voice communication on Android apps is possible via the Session Initiation Protocol (SIP) stack. This protocol originated in 2000 as a signaling protocol in support of Voice over IP (VoIP). With today’s move to IP wireless networks such as LTE, SIP is the core signaling protocol for voice over IP Multimedia Subsystems (IMS). In this post we will explore how to enable voice communication on Android apps by using the Android Session Initiation Protocol (SIP) stack. With the transformation of traditional networks as IP-networks, and the future of voice as a “data app,” expect media-rich and location-aware communication apps, where the smartphone plays a central role in personal communications. This means that developers can now create a new breed of voice communication apps like never before. This post assumes you are somewhat familiar with the Android platform and the Java language.

Read Enabling Voice Communication on Android Apps (source: Safari Books Online).

ceo

01 Jul

Security & Privacy on Mobile Apps, Part 1 – Introduction

This is Part 1 of a series on Security & Privacy for Mobile Apps.

(Note: in this article mobile apps means both native and webapps)


Are you Serious About Security on your mobile apps or webapps?

Security and privacy is an area that too often is not being properly addressed on mobile apps in general. From the product requirements, to the design and implementation of the mobile app, properly securing sensitive information means addressing this end-to-end: on the device/smartphone, through the network, and on the servers on the cloud.

Examples of sensitive information:

  • Personal Identifiable Information (PII)
  • Cardholder and other credit card information
  • Health/medical information
  • Tracking users/geo-location

And it is not only about collecting or not sensitive information, but also about 1) preventing others from gaining access to the sensitive data collected by your app, and 2) how to communicate to the user about how the app itself deals with such sensitive data.

As product owners and developers, we all should follow proper security and privacy guidelines, regardless of the kind of application. But when dealing with critical or sensitive information, we must go beyond guidelines and treat privacy and security as application requirements.


Increase in Apps with privacy & security requirements

Developers do need to be serious about security and privacy on their mobile apps:

But many developers find addressing privacy/security as challenging:

Why the need to be explicit about security and privacy?

Addressing security/privacy goes beyond protecting and securing data. It is a fact that security/privacy on mobile apps can quickly become confusing. And this impacts how we tell the users about what the application does with sensitive data. Typically this communication is done via privacy terms and/or policies that are hundreds of lines long and hard to read on a mobile device, thus many people simply skip reading it.

Simplifying privacy communication — a case for “Classifying Apps”?

Imagine that we can abstract and simplify how we communicate to the users the matters related to privacy/security. And idea is on classifying the Apps based on how they handle sensitive data, for example:

  • Class A — Collects data
  • Class B — Stores data
  • Class C — Shares data
  • Class D — Tracks the user
  • Any other?

Regardless, think about these classes when designing your application, and crafting your privacy policy documents.

Now imagine that these classifications are standardized, and with this, the Privacy wording for each these classes of apps is standardized as well — all with the goal of making such wording very clear and easy to understand, standard, and referenceable — similar in idea to how licenses such as GPL, MIT, Apache have been defined, standardized and used all around.

With such “standardization”, mobile apps would have a very clean, simple privacy policy that is familiar in wording and meaning, for example:

Privacy Policy — this application:

  1. Collects Data
  2. Shares data
  3. Tracks the user

Please click on the appropriate hyperlink for more information.

I would seeing an initiative of some kind to do just this (I’m investigating this as we speak). If you have any thoughts, please drop me a line. Perhaps there is something out there already that I haven’t seen yet. If there is nothing there yet, I believe it is worth it to follow up on this and come up with simple, consistent, familiar privacy messaging (and badge?) across platforms and applications.

Conclusion

Personal and sensitive information include any information that is critical for a user, for example credit card numbers, credit card validation codes, social security numbers, driver’s license numbers, name, addresses and date of birth, and other Personally Identifiable Information (PII). Any such information must be properly handled and secured.

As privacy continues to become more critical over time, with the number of apps exponentially increasing, and with potential legislation in the future, having clear privacy and security wording/messaging and responsibilities is very important. And as product owners and developers, you/we are responsible!

Related

/CEO

19 Oct

On Android, Distribution, Buzz, Pre-insalled apps and Crapware

Responding to Tomi‘s thread on ForumOxford, where he wrote: “The best phone in the world cannot take the mobile phone market, unless there is distribution.”

Yes. Which is exactly why Android seems to me that it will be widely adopted. And it will be widely adopted because for device manufacturers it is cheaper this way to develop a high-end handset — OSes are complicated (and thus expensive) things that are at the center of the handset. I expect handset manufacturers to leverage all that investment and research by Google; then add their touch via the UI.

Then there is buzz which drive sales opportunities. And buzz has a timing-window associated with it. iPhone has buzz. Android has buzz today. It is my impression that Nokia (and Symbian) missed that buzz window of opportunity.

Last, pre-installed apps are so year 2000. App stores are the new deck. As we are witnessing, app stores are very important for all smart-phones (and handsets that run apps). And as users get more educated and thus more sophisticated, users won’t settle for apps they don’t want. (Expect typical apps such as YouTube, Gmail, exchange, camera, etc. to be pre-installed though). And related to this, and something Jason (Paxmodept) wrote on his blog, is the anticipated “new” issue that will pop-up: Crapware — I’m afraid handset manufacturers will force pre-installed apps that are Crapware *and* that can’t be uninstalled unless breaking into the OS.

ceo

26 Jul

Resolving Device Fragmentation Issues – Mobile Web and Local Apps (and Google)

The Problem: Too many handsets, environments, and differences across platforms

The Solution: A single environment/platform for mobile apps

There you go, problem solved, no more fragmentation!

Google at MobileBeat 2009

Now that the “noise” level has dropped, it is my turn to comment on Google’s (Mr. Vic Gundotra) comment at MobileBeat2009 about mobile apps and the future:

“What we clearly see happening is a move to incredibly powerful browsers,” Gundotra said. “Many, many applications can be delivered through the browser and what that does for our costs is stunning. We believe the web has won and over the next several years, the browser, for economic reasons almost, will become the platform that matters and certainly that’s where Google is investing.” Gundotra added that Apple CEO Steve Jobs proclaimed “Build for the web” with the initial launch of the iPhone, a statement that met with resistance from developers: “I think Steve really did understand that, over the long term, it would be the web, and I think that’s how things will play out.”

Here Mr. Gundotra (Mr. G hereafter) emphasizes and reminds us that the main root problem with mobile applications is fragmentation and the consequences are higher cost of development and management of such mobile applications.

OK, fragmentation has slowed down mobile, and has resulted on higher development and management costs. But fragmentation will not go away any time soon. He said the Web has won, but on mobile it hasn’t. Because many applications can be delivered over mobile is not the same as it has won. The Web has won though from the perspective of “Services on the Web”. Mobile web run-time environments will, over time, continue to evolve, providing a rich development environment; I believe this will be the case, but this will take time, years, to happen. Now imagine a world where we have Google browsers and run-times and APIs — that would mean no fragmentation, right? Well, even with run-times from Google with its own APIs, yet another level of fragmentation will be introduced.

It is the way it is.

And not everyone will use Google tools and run-times and APIs. And not all developers want to develop their apps using Web technologies and models. And, mobile web apps are not sufficiently rich and transparent yet to replace local apps.

In any case, I will admit that I share Mr G’s vision on web run-times, as I’ve written many times before here in the weblog, but his message was so overloaded that I’m not really sure if that was Google’s official stand or just Mr. Gundotra’s point of view. For one, today Google is a large corporation, and I won’t be surprised if his comments caused some internal frenzy. You see, his view/solution to the issue of device fragmentation is “one platform”. But, that is exactly the goal of the Android team; reduce the number of mobile platforms out there.

Mr. G also implied that Google will continue to invest (greatly) on their (mobile) web platform with the goal of bringing it at the same level to local (non-web) platforms such as Android. This should translate to extending the browser/web run-times with the APIs and access to device functionality and HW that provides overall greater richness. That translates to investments in Chrome “OS” and the Google APIs including Gears, which are proprietary APIs. As a side-note, why Google didn’t participate on BONDI, which defined APIs for web run-times for application invocation, UI, location, camera and other, might reveal either “political” or proprietary mentality that should concern you (as it concerns me). BONDI and Gears are competing technologies, but they don’t have to be.

But all this push to web run-times and Chrome “OS” doesn’t mean that Google will stop investing on other. You see, Chrome “OS” will become a very strong brand. But Chrome “OS” is a misnomer, as it is not a real OS. And to be able to expose and offer the powerful browsers and rich user interfaces and experiences that the browser-based apps of the future will need, again, access to the functionality and HW underneath is needed – and for this a real underlying OS will exist and perhaps with it an application environment on top of that; in short OS = Linux, App environment = Android. In other words, Google’s investment on Linux and Android won’t go away. With this approach, Google has all the components, from the OS, to the app environment, the web-run-times and the applications to lead and keep it moving ahead, red-shifting from the competition.

App Stores are Dead, Not

Some folks have interpreted Mr. G’s comment as the end of App Stores; see Google forecasts browsers will beat out app stores (FierceMobileContent). But it is not; not sure why that conclusion. App Stores are nothing else than repository/catalog of applications, those being local or web or widget or whatever, for the purpose of discovery regardless of the application model. Thus, expect Google App Store to grow in the future to include widgets, web-based and other apps.

Mr. Jobs, Apple, The View of the Future, But Reality Strikes

Mr. G assumes Steve Jobs “saw the future” when at first the iPhone development was web-based only. Maybe he is right. But the iPhone had an SDK, perhaps primitive, since day one (used for the development of internal apps such as phone dialer, contacts, calendar, and so on). Why would Apple limit access to it? One reason could have been that the SDK was not ready for prime time. But Jobs is a coined operated individual, let’s not forget that. Maybe Mr. Jobs wanted to give access of the SDK (which allows for extremely rich and profitable applications such as games and music and video) to just a few privileged ones — the big power houses such as Sony and others, while the rest of applications by the developer community were to be done via simple Web (perhaps for free). Who knows. But that hypothetical plan didn’t work, and once Apple recognized the real power of the *developer community*, it reacted and offered the SDK; in the end, everyone won, you and me. And the unplanned succeeded. And this same exercise also showed the reality that today mobile web apps are not ready for prime time as compared to the richness and capabilities of local/native apps. There you have it. Native apps are kind today. :-)

Today vs. Future

Let’s not confuse theory and practice. Let’s not forget why we are doing this. Today is about generating revenue while minimizing cost of development. Tomorrow is about the same, but lets learn and reduce such costs related to investment and operations, and part of this plan is reducing device and application fragmentation. This is important for Goggle as it is about applications and information (and the infrastructure that powers this). Google has two strategies on applications and fragmentation: one Web-based and one local/on-device (Android). Google has the whole SW stack including the OS. And on the top, it is about the information (and its meaning) w.r.t users/people. But it is IMHO that local apps are here to stay; because limiting apps to browser-based apps will be too limiting, in functionality and richness and in programming models and at times in speed. And because it is about the developer community (internal and external), “limiting” will translate to less innovation. And I will even predict that even Chrome OS will allow the user to “switch” to an advanced mode, the native/local apps mode (or a hack will exist for it).

And Mr. Gundotra’s comments are all about the future… So time will tell. And it should not be a too distant future (5 < years)... ceo Related to this:

17 Jun

Call for Submissions – VentureBeat Announces the “It’s the application, stupid!” Competition For Outstanding Mobile Apps

VentureBeat Mobile Trophy

VentureBeat is looking to recognize Mobile innovation at the second annual MobileBeat Top Startup Competition.

Last year the awards went to firms such as AdMob and Loopt. This year the competition shifts to mobile applications and services, with 50 finalists to be determined and a final 14 to present live at MobileBeat on Thursday July 16th.

Top Startup Submission Rules:

  • Startups must complete and submit a form by June 30, 2009 for consideration
  • Fifty finalists will be announced on July 2nd on Venturebeat.com. Voting will then be open to the public to select the top seven companies per sector.
  • Seven finalists from each category will present for five minutes each to the MobileBeat audience determined by judges as to avoid any vote manufacturing.
  • Nominees must be younger than three years old. Special consideration will be given to companies that are launching for the first time.

Winners to be announced at the MobileBeat Conference July 16th, San Francisco CA San Francisco.

Directly following each two-minute presentation, a panel of judges will provide feedback in rapid fire. After final deliberation in the afternoon, winners will be announced.

Submitting a company for nomination is completely free. For more information visit the startup competition website.

MobileBeat 09 will take place on July 16, 2009 in the Parc 55 Hotel in downtown San Francisco. The theme of this year’s show is “It’s the application, stupid!”, focusing on mobile applications’ recent explosion in popularity.

See registration information.

Speakers at this year’s MobileBeat include: Dr. Tero Ojanperä (Nokia), Russ McGuire (Sprint Nextel), Matt Murphy (Kleiner Perkins iFund), Rick Segal (Blackberry Partners), Nagraj Kashyap (Qualcomm Ventures), Aditya Khurjekar(Verizon), and Michael Rayfield (Nvidia)

ceo

30 Apr

On Mobile Applications, Platforms and Monetization — “Show me the Money”

I’ve been keeping track of a very interesting thread at Forum Oxford (FOROX) on the topic of Android phone dissapointing developers (w.r.t. iPhone), with Jason Delport, Alex Kerr, William Volk (who started the thread) and others adding their different perspectives on the matter. All these guys are mobile experts so what they say resonate with me…

I like Jason’s responses as there is no bias, just pure pragmatism (i.e. he has been burned before); he makes a living building mobile apps, so for him it is about business and making money. Period. Jason’s take on why Android is dropping the ball is as follows:

  1. User’s don’t want to sign up to Google checkout
  2. There are plenty of places to find illegal copies of paid Android apps
  3. The store is over cluttered with crap apps
  4. The store has a poor design and has a rubbish user experience compared to the iPhone app store
  5. Paid apps were launched later than free apps and a tone was set in the market that apps were, and should be, free.

For which I respond as follows:

On #1, Google should do one of two: 1) require and capture credit card information the first time a user tries to buy a premium application, or 2) integrate with the network operator’s billing. On #2, true, but #1 is the main issue. On #3 and #4, I totally agree, plus, the good apps are hard to find! A better way to find applications is needed. On #5, I totally agree as well; the wrong expectations were initially set.

Alex followed writing that developers should be focusing on the platforms that are most “useful” to as many people as possible in the world… these being J2ME, Web and S60.

But useful is *very* relative. For talking on the phone? For writing applications? For deploying and making money from? I used to think as Alex… yes, it all sounds reasonable — target the platforms that (in theory) have the largest subscriber reach. Well, that is, until you take into consideration “Show me the money”, as Ajit likes to say.

From the “show me the money” perspective “rich development platforms and ecosystems” have proven, finally, successful. When I say “rich development platforms and ecosystems”, ecosystems go beyond app repositories, and it is about all the details that make it work, which includes user experience, integrated billing/payment, social and not, feedback system, and all the goodies a good/properly designed app store is all about.

I remember the debates between Ajit and myself over Web vs. local apps a couple of years ago, including at JavaOne Motorola Keynote, where I defended local applications while Ajit debated that “AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development” (note that he wrote J2ME but he really meant local apps). Today I can humbly say that I was right about local apps, and that “AJAX will not replace local apps as the platform of choice for developing mobile applications”. At least not yet. Ajit was/is right that mobile web apps will be huge, but they will in a different way as when it comes to richness and user experience and making money, today it is about a local apps.

And it took Apple to show “us” the way.

App Stores have proven central for developers (i.e. “show me the money”), and for subscribers (to easily find and download apps). And as a consequence, have proven beneficial to network providers themselves – gosh, it has taken so many years for network operators to finally open their eyes, not be so paranoid and over-controlling, and agree with common sense — it is an ecosystem after all. So now, all are converging into similar solutions such as iPhone’s App Store. They have to – the power is shifting to the subscriber itself, and to the developers who are bringing applications, software to the market. And those platforms that don’t play nice with the ecosystem, will fail.

So the argument that subscribers would not download local apps, argument a number of us didn’t agree with and defended against over the years via our blogs and apps, resulted in a non-issue. Yes, users will download rich, useful applications, and even better, will pay for them if given ways to easily find, pay for, and download those applications. While other types of apps such as Web and SMS, well, subscribers do like, but for free! Don’t you agree? What this translates to is into business models centered on the subscriber vs. “the other side of the subscriber” such as businesses, etc.

A word on the various platform

A word on iPhone: the device, the platforms rocks. I have an Android (personal) and an iPhone (work). And the iPhone is a beautifully designed piece, overall, from hardware to software. AT&T will hurt and cry if/when iPhone goes to other operators. As a sidenote, see ReadWriteWeb article by Sarah Perez titled The State of the Smartphone: iPhone is Way, Way Ahead, where she explores a recent report by Flurry that concludes that the iPhone is way ahead when it comes to mobile apps (based on the number of developers, apps and consumers). But, let’s take this report “with a grain of salt”. Why? Because it can be biased as follows: the majority of the developers using their analytics instrumentation code might just be iPhone developers, thus, the sample-set is biased by default.

A word on Android: just give it time. Android has the potential to be everywhere – phones, internet appliances, cars, etc. around the Globe, and thus many different types of developers (mobile to embedded). And it very well might allow developers to enter “emerging” markets easier. Judging Android after 6 months or so means nothing in the grand scheme of things. Time will tell (but I stand by what I’ve been saying thought).

A word on BlackBerry. They are getting it, but imposing a minimum app price of $2.99 — because “they value the efforts of developers” is bogus and is an attempt to sound developer-friendly. Let the market decide pricing!

A word on Nokia: they are trying with Ovi, but keep it simple! I really hope Nokia hits the ball out of the park –but they should consider simplifying their portfolio tho, see On Nokia’s App Store Strategy. Nokia’s attempt to do integrated billing for their App Store and (eventually) requiring Credit Cards mean they are thinking the right way.

A word on J2ME: Java ME suffered over the years due to 1) the process that created it was too slow to adapt, allowing for inconsistent implementations and incomplete API-sets, 2) its security model, and 3) lack of integrated app repository (i.e. app store). I still believe it has potential to be the platform of choice for mid-level phones. Specially with the latest MSA API-stacks and MIDP3 that (I hope) will come out later this year. And today,if you have the right market and channels, go for it.

A word on Web: best channel for apps that easily bring “generic” content out to people. Huge potential, especially with efforts such as BONDI and HTML 5 persistent data and the Canvas elements. In any case it is always a good idea, if it is applicable, to have a mobile web version of your app.

A word on short messaging (regardless of SMS or Twits): best channel for notification-like distribution. Second to none. True SMS is way to expensive and prohibitive for many; SMS though is a cash-cow for network providers who must be terrified of Twitter. If targeting notification-like app such as promotions SMS and Twitter is the way to go.

A word on voice apps: I wish we spend more time investing/researching this mode of interaction.

A word on SIM-based apps: The SIM card will always be at the center of mobile apps – directly or indirectly. New technologies such as JavaCard 3.0 and Smartcard Web Servers (SCWS) have the potential of bringing a new breed of mobile applications. Still developing SIM-card based applications is a niche and very network provider oriented, but if you have the relationship w/ the carrier, go for it!

And what the best type of application is? The hybrid app! This is a rich *local* app that is very good at consuming and rendering web content, as well as direct messages (i.e. SMS, Tweets). In the future, mobile web has tremendous potential but again, it is about making money *today*.

So in conclusion, we have to agree that today, integrated app stores that caters subscribers directly is the best channel for subscribers, and developers, and for operators as well. The potential for reaching more subscribers via J2ME, S60, and Web do exist, but but one thing is to create and attempt to deploy apps for those platforms, and the other is those apps getting payed for, downloaded and used.

As a recent report by IDC (Scott Ellison) titled “Developer Strategies for Success Shift as Apple iPhone Apps Store Passes 1 Billion Downloads” concluded:

Apple has demonstrated — again and again — that the success factors in mobile can change in the blink
of an eye — indeed in as little as 3 quarters in the case of the Apps store. The Apps store is increasingly
central not only to Apple, but to any developer or company seeking to play in the mobile applications and
content space. And understanding the shifting success factors within the Apps store is key to success
both on the device and in the digital marketplace that continues to remake mobile.

ceo

P.S. Anders Borg (Abiro Mobile News) has written an excellent analysis of this blog piece — see The state and future of mobile applications. And I like very much Michael Yuan‘s comment saying “What developers want is to address the “maximum number of people who are willing to pay”; exactly!

15 Mar

Reminder this evening (Sun Mar 15) – Mobile Web Apps & Widgets Meet-Up @ Driskill

A reminder that this evening, Sunday March 15 don’t miss the “Mobile Web Apps & Widgets Meet-Up” at 5:00pm:

  • Event: Mobile Web Apps & Widgets Meet-Up “Find out about your chance to win £20,000″
  • What: Informational Meeting
  • Host: Vodfone/Betavine & OMTP
  • Start Time: Sunday, March 15 at 5:00-8:00pm
  • Where: Driskill Hotel Bar

To see more details and RSVP, follow the link below:
http://www.facebook.com/n/?event.php&eid=56573382794&mid=238ec8G3289174dG3ff128fG7

Or if you don’t use Facebook, just show up.

ceo

02 Jan

Mobile Apps in 2009: Local/Native, Mobile Web, App Stores

Happy 2009 New Year to all my readers. My first post of the year is about mobile applications: local/native vs. web, and app-stores.

App-stores have been shifting the balance on application development and distribution (back) towards local/native applications. I don’t mean to undermine mobile web which will continue to be very important and very large for access of information of type “web content”. But the reason for this is the same reason I’ve been preaching for a long time: the ability to deliver/maximize “application richness, functionality and experiences” – which (today) maximizing these is only possible via local/native applications. This is the same topic took Ajit and myself into a debate at JavaOne’s keynote a couple of years; that was fun.

What I’m describing above can be seen on the iPhone which is the best mobile web handset today, and which redefined and raised the bar on mobile web applications, yet the really cool applications are local/native, and more importantly, developers of local/native applications seem to be the ones who are generating (receiving) the most revenue – after all, it is about making money. And this trend will continue… I do believe that in the future mobile web will be able to match the richness and functionality of local/native applications, once the proper APIs and functionality are put in place and become standard, and that today a happy medium are local/native applications that consume mobile web content; i.e. hybrid apps providing the best of both worlds.

And when combining the above with App-stores, which provide for the application discovery and revenue streams for developers, the market place becomes very attractive and thus active.

But to be successful, app-stores must exhibit certain characteristics:

  • From the end-user perspective: the app store must be seamless and well integrated into the user experience. Downloaded applications must work. There must be a good selection of high-quality apps. Integrated checkout/payment is easy and straightforward and secure. The end-user is in control, including influencing how applications will perform on the market (via feedback that influences ranking).
  • From the developer perspective: there must be a low cost and barriers to entry and distribution. Must provide application visibility (see below). Good revenue model. Provide feedback back to developers for improvement.
  • Application visibility: the app store must provide the means for good application visibility. Already established applications are ranked appropriately based on user feedback, while new applications (including new versions) go into a different bucket that allows them to be visible regardless of ranking (perhaps for a period of time).
  • As Ajit writes, must provide a true ecosystem (that benefits everyone: developers, network providers, the end-user, and so on).

Part of the above is why the iPhone has been successful. And is also the reason that I expect the Android app store to do well once it starts paying back to developers — it is just then when the Apple and Android stores can be compared.

There are app stores for Java ME, for example GetJar. The problem faced by GetJar is that there are things that are out of their control, such as cost and barriers to entry (due to fragmentation and certifications and fees and it is just a pain-in-the-neck to deal with network operators issues in general), and not being well integrated (seamless integration) into the overall user experience.

For years I’ve been attributing the lack of integrated solution for Java ME that works (per the above) for application discovery and download and revenue share, as one of the top the reasons why Java ME has failed to maximize its opportunity. As a member of MIDP expert group, this is an important lessons learned for me, that sometimes you do need to include such functionality into the platform vs. expecting 3rd parties to solve the problem; this seamless solution is still needed for Java ME…

On Goodbye 2008 and welcome 2009 and some predictions on mobility I made some predictions on app stores, which I will repeat here:

  • Google will introduce a checkout process for its app store, and developers wanting to make money will notice; the Google app store will explode with a large number of applications.
  • App stores will continue to have its huge effect on mobile apps and distribution. Due to the revenue and fast distribution models offered by iPhone and soon Android app stores, developers will first target such local applications (vs. mobile web). An even larger number of local/native applications will be created and distributed via app stores for Android and iPhone.
  • The BlackBerry app store will be somewhat successful.
  • Someone will introduce an app store for mobile web that goes beyond an application catalog. dotMobi will take leadership by going beyond an application catalog but also providing an associated business/revenue model.

Last but not least, and related to this topic, check out Paul Golding (Wireless Wanders) on his video blog entry Mobile 2008/9 all about App Stores where he discusses and provides his insight on why app stores have been important in 2008 and how important they will be in 2009… right on.

Also related to this see Ajit on Mobile Web Megatrends event – Making money from Appstores – Singapore – April 27 and 28, as well as his related thread on ForumOxford.

ceo