Tagged: windows phone

Tiggzi And The Backend as a Service Ecosystem Map by Kinvey

Our friends at Kinvey posted an update to their really nice Backed as a Service Ecosystem map. Some call it the subway map, the Pacman map, or you can also look at it as “Where we fly map”.

Thank you to Kinvey for including Tiggzi, we really appreciate it.

Tiggzi is right there:

A lot has changed in Tiggzi in the past couple of months so I would like to offer an update. Hopefully the map can be updated.

I don’t believe Mobile SDK is the best fit for Tiggzi (and other players such Sencha and Appcelerator). Tiggzi is much more than a mobile SDK, in fact, it’s a mobile app platform (more about it below). One suggestion is to add a new line that would include Tiggzi and others such as Appcelerator.

Tiggzi is a mobile app platform, and one of its biggest components is the mobile app builder.


Drag and drop app builder

It’s a cloud-based, drag and drop builder (IDE) for creating HTML5, jQuery Mobile and PhoneGap apps. As Tiggzi app builder uses jQuery Mobile and PhoneGap to create apps — it’s probably best to list it on a separate line with lines going to jQuery Mobile and PhoneGap (already exists). Again, this is just my opinion.

In early July we launched Backend Services under io.tiggzi.com. The first feature in the backend services is a cloud database.


Database features


Database web console

We are also working on Push, File storage, Server-side code, and Analytics features. I think there should be a line going from Tiggzi to BaaS line (io.tiggzi.com) – similar to Sencha’s connection to Sencha.io.

To summarize, this is Tiggzi mobile platform:

  • Visual UI builder (HTML5, JavaScript, CSS, libraries such as jQuery Mobile, PhoneGap, etc)
  • 3rd party REST API services
    • Plug-ins (pre-packaged API services and pages)
  • Backend services
    • Database
    • Push (available soon)
    • File storage (soon)
    • Server-side code (soon)
    • Analytics (soon)
  • HTML5 app hosting
  • Binary build

The New Paradigm: Cloud Services, Cloud Tools

This article was originally published in Software Developer’s Journal.

Cloud Services

In the past year or so, we have witnessed a major shift from client-server to client-cloud. This shift is primarily
fueled by two factors: mobile devices exceeding desktop computers and the thousands of different APIs available on the Internet today. What started in early 2000 on eBay and Amazon has become a real revolution in 2012 with thousands of companies, from Twitter and Facebook to AT&T, offering cloud-based services.

REST API

One of the most common ways to access private or public service APIs is via REST requests.

In the client-server approach an organization builds applications that consume its own internal content and
resources. However, even large IT organizations such as AT&T, Verizon and Amazon have come to realize that
they are no match for the social consumer and social enterprise developers out there. By making APIs publicly
available, these organizations hope that developers and “citizen developers” will come and build applications
and mobile apps on top of their services.

Citizen developers at work

Analysts at Gartner see a trend toward app creation independent of IT. They predict that by 2014, citizen developers – employees outside of IT and software development – will build 25% of new business applications. In 2007, they built less than 5%.

One of the best-known API success stories comes from Amazon: Its cloud service APIs let outsiders access
the company’s massive data centers. Twitter, with its deceptively simple 140-character message model, exploded thanks to its API. In fact, you probably read and write tweets via a Twitter application or mobile app rather
than going directly to Twitter’s Web site. Facebook’s Graph API has spawned a whole industry of apps to support its hundreds of millions of users.

Just looking at popular ProgrammableWeb site that lists close to 5,500 APIs (at the time of writing this) and 6,500 mashups or apps created that consume the various APIs. The city of San Francisco, already a mecca for startups, technology, and innovation, has made a big push into attracting developers by making city data and other date from its data.SFgov.org Web site available via API. For example, the city’s MUNI (city bus service) API is available for developers to build apps with using information about bus stations, schedules, and arrivals. Even the United States government jumped on the API bandwagon by making available data.gov, which provides public access to high-value machine-readable data sets generated by the U.S government.
Continue reading

Tiggzi: Build Windows Phone Apps With jQuery Mobile, PhoneGap

You can now build jQuery Mobile apps in Tiggzi and export the app for Windows Phone (with PhoneGap).

VS Project is a Windows Phone PhoneGap project. We will be adding binary build as well. To get a binary, you have two options: 1) build it yourself; 2) take it to PhoneGap Build.

Create Windows Phone App with jQuery Mobile, PhoneGap and Tiggzi App Builder in 3 Easy Steps

Yesterday we attended mobile hackathon sponsored by Microsoft and PhoneGap. The goal was to build a PhoneGap app and install in on Windows Phone. We used Tiggzi App Builder, PhoneGap Build and very quickly installed an app on Windows Phone. Thanks to @jccim for inviting us and giving us a brand new Windows Phone for testing.

Step 1.

Build an HTML5/jQuery Mobile app in Tiggzi Mobile App Builder:

Step 2.

Export the app as HTML/JavaScript/CSS:

We will be adding Windows Phone support to Tiggzi in May (first source code export, followed by binary build).

Step 3.

Upload the app to PhoneGap Build, download the Windows Phone version:

You are done!

Mobile apps choices: Native Apps vs Web Apps

This post shows various differences, in various categories between building native mobile apps and web mobile apps. I know that everyone has their own experiences and opinions, which I would love to hear. So, don’t hesitate to hit the comments at the end of this post.

Native App Web App
Platforms
Platform Five different mobile platforms:

  • iOS
  • Android
  • BlackBerry
  • webOS
  • Windows Phone
Other notes:

  • Android also experiences a rather big fragmentation in terms of Android versions to various screen size and features from different phone manufacturers and tablets.
  • There are also Symbian and MeeGo, however, they are getting very little traction today.
Mobile web browser. Differences still exist as different versions of mobile platforms run different browsers, with different support for various latest HTML5 features.
App discovery, monetization, support
App discovery App Store – proven and popular. A number of options:

  • Same as desktop apps today, search, URL, etc.
  • Sold through web stores like Chrome app store.
  • Sold through standard app stores (Apple, Android, BlackBerry, etc) by placing the web apps inside a native wrapper. Usually called a hybrid app.
App approval App is published to an app store and goes through review process before being approved Instant, no approval process
App installation Downloaded from app market and installed Open URL in a mobile browser, or another popular option is to create a short cut on the phone. The short cut gives more of a “native app” feel.
App update Updated app goes through review process, then downloaded and installed No approval or download process. Just update the mobile web app and everyone gets the new version.
App support, maintenance, adding new features The more platforms you support, the more challenging and difficult it becomes supporting and adding new features.

It’s not uncommon to have different native apps for iOS and Android with different feature sets. The app for iOS is usually more mature and stable.
Supporting and adding new features is much simpler, as you write once and it’s available on every platform. Write once, deploy anywhere.
Monetization App Store – proven monetization strategy. Web apps have a number of options:

  • Each app has its own monetization strategy
  • HTML App Store, like Google Chrome Web Store
  • Standard App Store – putting apps inside a native wrapper/shell (hybrid apps)
  • Selling access or token in standard App Store and then getting access to mobile app
Porting/add new platform Need to learn another mobile platform
Need to learn platform’s “UI approach”
Nothing – build once, run anywhere (almost). Might need to tweak the UI a little bit to “fit” it better in to the underlying mobile platform. Difference in browsers and supported features.
Experience
Performance Faster for some UI functions, especially when heavy graphics are involved. HTML5 improves on the infrastructure of the Web and makes applications faster and more functional. JavaScript rendering engines are getting faster and are good enough for most Web applications.
User experience Native application have a lot of UI effects, usually more developed UI “logic”. Native apps can “feel faster” and screen sizes on mobile devices makes native apps more enticing as well. Can be “very good”. For example, an app like Gmail. Will continue to improve and get better.
Perception Today most people associate mobile apps with something you download and install. We are so used to desktop web apps, so it’s just a matter of time before we “get used” to mobile web apps. It’s also important for more and more (good) web apps to become available.
Phone features
Video/Audio Built-in Possible with HTML5
Offline or disconnected apps Native apps can work in disconnected mode. Offline mode can be achieved with HTML5.
Full screen mode Built-in. Can be in full mode by hiding browser address bar.
Accelerometer Built-in. Possible with HTML5.
Push Possible with native platforms. Possible with HTML5 technologies.
Integration with phone services Good integration with phone services:

  • Contacts
  • Calendar
  • Other applications
Still somewhat limited with HTML5. But, more and more apps like that get data from the Internet, and not the client device.
Integration with phone hardware Integration with phone hardware

  • Camera/Video
  • GPS
Some support via HTML5 is now available for camera/video.
Enterprise, development
Developer Skills Need to learn one or more of the mobile platforms and their underlying programming language/SDK:

  • iOS (Objective C)
  • Android (Java)
  • BlackBerry (Java)
  • webOS (HTML/JavaScript)
  • Windows Phone (Silverlight)
Every platform will also have its own approach and style to developing and designing mobile user interfaces.
Developers can use HTML, JavaScript and CSS to create mobile web apps without of learning new languages to code native applications. But, that doesn’t mean that some training won’t be necessary to adapt exiting HTML/JavaScript/CSS skills to mobile development.
Development cost Expensive, as still relatively small number of developers master these skills. Can be significantly cheaper. Large number of developers who posses web development skills – HTML, JavaScript, CSS. But, some training might be needed to learn how to develop UI for mobile apps.
Mobile development frameworks Every mobile platform has its own SDK. Even though Android and BlackBerry both use Java, applications are not compatible. BlackBerry plans to allow running Android applications on BlackBerry devices in the future, probably inside a special wrapper (virtual machine).

  • iOS (Objective C)
  • Android (Java)
  • BlackBerry (Java)
  • webOS (HTML/JavaScript)
  • Windows Phone (Silverlight)
A number of options available today for building web mobile apps:

  • Take “do it yourself approach” or adapt any existing framework to work on mobile web
  • jQuery Mobile
  • Sencha
Tools that can build both native and mobile web apps:
Tiggr Mobile (coming up), PhoneGap, Open plug, Adobe Flex Mobile, Titanium Appcelerator, Corona SDK
Enterprise integration Existing infrastructure could be reused but also need service layer to communicate between client (mobile) and server. Can use REST, SOAP or custom communication protocols Hessian, Protocol Buffers. Existing infrastructure can be reused.

Virtually any application we used to have on a desktop from email to drawing to CRM, is now available as a web application. I think a similar move will happen in mobile, as more and more natives apps are moved to become mobile web apps.