List of 83rd annual Oscar winners - Boston.com

List of 83rd annual Oscar winners... List of 83rd annual Oscar winners - Boston.com

Android Developers Blog: Heading for GDC

Android Developers Blog: Heading for GDC

BlackBerry features and their impact on battery life

Really an interesting article from RIM about the impact of your application feature on the battery life.

BlackBerry features and their impact on battery life

Different ways to make an HTTP or socket connection in BlacBerry

>

Procedure

The BlackBerry Java Development Environment (BlackBerry JDE) application programming interface (API) reference includes five ways to make a Hypertext Transfer Protocol (HTTP) or socket connection.

BlackBerry Enterprise Server using the BlackBerry Mobile Data System (BlackBerry MDS) Connection
BlackBerry Internet Service
Direct Transmission Control Protocol (TCP) stack
Wi-Fi network
Wireless service provider Wireless Application Protocol (WAP) 1.x gateway
Wireless service provider WAP 2.0 gateway

BlackBerry Enterprise Server using the BlackBerry MDS Connection Service

The BlackBerry MDS Services are included in the BlackBerry Enterprise Server software and handle all browser or connection requests and route the requests accordingly. Data flowing between the BlackBerry smartphone and BlackBerry Enterprise Server is encrypted with Advanced Encryption Standard (AES) or Triple Data Encryption Standard (Triple DES). A connection made through BlackBerry MDS provides seamless roaming across wireless service providers that support BlackBerry smartphone service.

By default, all BlackBerry smartphone models, except the BlackBerry 6500 Series and the BlackBerry 7500 Series, use BlackBerry MDS. The following is an example:

(HttpConnection) Connector.open ("http://www.testserver.com");

To make sure that an application uses BlackBerry MDS Services as its connection pathway on all BlackBerry smartphone models, append the deviceside=false parameter to the end of the URL. The following URL is an example:

(HttpConnection)Connector.open ("http://www.testserver.com;"+
"deviceside=false");

BlackBerry Internet Service

Applications are also able to make connections through the BlackBerry Internet Service. This connection route is available to third-party developers and is subject to an application approval process. Data flowing over this connection is not encrypted. Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) or Secure Sockets Layer (SSL) can be used to secure a connection. A BlackBerry Internet Service connection provides seamless roaming across wireless service providers that support BlackBerry smartphone service. Currently, this transport is only available to BlackBerry Alliance Program members, subject to approval. Information about the BlackBerry Alliance Program can be found at the following web site: http://na.blackberry.com/eng/partners/alliance.jsp

Direct TCP stack

For BlackBerry smartphones running BlackBerry Device Software 3.8 and later, a direct TCP stack is included, which allows a direct TCP connection to be opened from the BlackBerry smartphone without using BlackBerry MDS.

For BlackBerry smartphones operating on the iDEN network, including the BlackBerry 6510 smartphone, BlackBerry 7510 smartphone, BlackBerry 7520 smartphone, and BlackBerry 7100i smartphone, a direct TCP connection is used if the deviceside parameter is not present. BlackBerry smartphones not operating on the iDEN network use BlackBerry MDS as the default connection if the deviceside parameter is not specified.

If BlackBerry MDS is not available at the time of connection, the BlackBerry smartphone reverts to direct TCP.

For the BlackBerry smartphone to use direct TCP, the user name and password fields must be completed under Options > TCP or supplied by the application. this article explains how to specify access point name (APN) information in a direct TCP connection.

To override the default behaviour of the default connection on the BlackBerry smartphone, the deviceside parameter must be included within the connection statement. The following is an example:

(StreamConnection)Connector.open("socket://testserver:600;"+
"deviceside=true");

Wi-Fi network

A Wi-Fi enabled BlackBerry smartphone is able to connect over a Wi-Fi network to the BlackBerry Infrastructure. The BlackBerry Infrastructure exists between a BlackBerry smartphone and the BlackBerry Internet Service or BlackBerry Enterprise Server, allowing for connectivity to these components. A BlackBerry smartphone can also be configured to connect directly to a BlackBerry Enterprise Server using a virtual private network (VPN) connection over a Wi-Fi network. What this means is that applications that are making a connection through a BlackBerry Enterprise Server or BlackBerry Internet Service (options 1 and 2 ) can have their connections automatically routed through a Wi-Fi connection without any special logic required in the application. Applications can also make a connection over a Wi-Fi network directly to their destination server, bypassing the BlackBerry Infrastructure, BlackBerry Enterprise Server and BlackBerry Internet Service. To specify that a connection must be made over a Wi-Fi network, the interface=wifi parameter is used. The following is an example:

(StreamConnection)Connector.open("socket://testserver:600;"+
"interface=wifi");

Wireless service provider WAP 1.x gateway

The connection string uses WAP parameters, which are hosted by a wireless network provider. Not all wireless service providers support connections through their WAP gateway. Contact the wireless network service to find out if support exists and to obtain a listing of their WAP gateway parameters.

The following is an HTTP connection over a WAP gateway:

(HttpConnection)Connector.open("http://wap.google.com;"+
"WAPGatewayIP=127.0.0.1;WAPGatewayAPN=carrier.com.gprs")

The WAPGatewayIP and WAPGatewayAPN values are required parameters. Each parameter specified must be separated by a semicolon. The following is a table of supported WAP parameters:

Parameter	Description
WapGatewayIP	IP address of the gateway.
WapGatewayAPN	APN for General Packet Radio Service (GPRS) networks only. For testing purposes, you can use rim.net.gprs
WapGatewayPort	Gateway port value. If port 9203 is specified, Wireless Transport Layer Security (WTLS) is used unless WapEnableWTLS=false is specified.
WapSourceIP	IP address of the source.
WapSourcePort	Source port value.
TunnelAuthUsername	User name for APN session, when Password Authentication Protocol (PAP) or Challenge Handshake Application Protocol (CHAP) authentication is used.
TunnelAuthPassword	Password for APN session, when PAP or CHAP authentication is used.
WapEnableWTLS	Explicitly turns on or turns off WTLS. If this parameter is not specified, WTLS is used by default for connections to port 9203.

Wireless service provider WAP 2.0 gateway

BlackBerry Device Software 4.2.0 and later includes the ability to connect through a WAP 2.0 gateway. This is done by locating the service record on the BlackBerry for the WAP 2.0 gateway and using its UID when making the connection. The following code sample demonstrates how this can be done.

 

ServiceBook sb = ServiceBook.getSB();
ServiceRecord[] records = sb.findRecordsByCid("WPTCP"); 
String uid = null; 
for(int i=0; i < records.length; i++) 
{
    //Search through all service records to find the 
    //valid non-Wi-Fi and non-MMS 
    //WAP 2.0 Gateway Service Record.
    if (records[i].isValid() && !records[i].isDisabled()) {
        if (records[i].getUid() != null && 

                 records[i].getUid().length() != 0) {
            if ((records[i].getUid().toLowerCase().indexOf("wifi")==-1) 

&& (records[i].getUid().toLowerCase().indexOf("mms")==-1)) {
                    uid = records[i].getUid(); 
                    break;
            }
        } 
    }
} 
if (uid != null) {
    //open a WAP 2 connection
    Connector.open(_url + ";ConnectionUID=" + uid);
} else {
    //Consider another transport or alternative action.
}

Mobile thick clients vs thin clients

For many application developers, the fastest, easiest way to introduce a mobile solution was to "chop down" an existing Web-based application. Users that had a device with a browser could then access the applications. However, because the resulting applications were not designed for the navigation capabilities of a mobile device or the smaller bandwidth, the user experience suffered. These problems can be solved by using a thick client instead of a thin client.

With a thin client, there is nothing running on the device except the presentation. All the content is on the host. The data, along with the rules to display it, are sent down and rendered on the local machine. Everything is done on the server; every request requires going back to the host. With a thick client, however, the presentation engine is on the local machine, which does the work.

The need for thick clients is driven by the complexity of the information and the presentation demanded by
mobile users. Mobile users, too, want robust applications and a good user experience. Years ago with the
PC, users went to a Web site and got straight HTML. PC users said, "That's not good enough." Then came
dynamic HTML, Java applets, Flash, and great plug-ins.

It depends on

• what application you want to build
• which audience you want to target
• Operating cost
• Billing and revenue models

Thin clients are good for:

• Displaying regularly changing information eg. news.
• Casual one-off browsing, where the user is unlikely to ever need to come back and benefit from having any sort of state remembered, and not being able to access any content is not a serious problem (due to lack of signal, etc).
• Very changeable data with simple display requirements that change unpredictably over time, with minimal data entry requirements.
• Situations where reliable network connections are guaranteed – either fast connections, or very small nuggets of content that can be found very quickly.

Thick clients are good for:

• Repeated user experiences – local secure caching can reduce data entry, always a significant pain point on mobile.
• Intelligent data delivery can reduce costly data overheads whilst providing faster responses for the user for known types of data set.
• High interactivity and improved user experiences with many potential data visualisation models and on-client validation (minimising round trip requirements to the server, which cost money and time).
• Improved branding around content, which only ever has to be downloaded once rather than at the start of ever session – handsets rarely dedicate persistent storage to browser caches so ever visit to a branded site reloads many Kbs of images, CSS etc.
• Real security, guaranteed – there are known issues with Wap security which can even affect Wap2 browsers running through legacy APNs.
• Offline access – content can be stored locally to browse even when there is no signal (eg. Tube maps), data entry can be performed when required and then submitted to a server asynchronously etc.
• Data roaming can be incredibly expensive so for content like travel guides designed to be read abroad, or interactive services for which Java can choose to use SMS instead of GPRS, there are big cost savings to be had.
• Precise optimal rendering of certain types of content, for example barcodes (used for ticketing etc) which would be useless if the handset decided to rescale them badly as can happen when displaying MMS messages or images in browsers.

First is the ability to do local processing and local data storage. With a thin client, modifying one item could require making several trips back to the host. And, because the bandwidth in the wireless world is so small, bringing pages down is a long, arduous task. A thick client, however, enables mobile users to work offline with the local data that is brought down; everything is done locally.

The advantage of a thick client's local processing ability can be seen when a user makes a mistake while entering data. With a thin client, the user would be prompted again, requiring another trip. With a thick client, you could use an "if" statement to determine if the information is correct before sending it to the host, which saves time.

How To - Use the preprocessor in BlackBerry JDE

RIM Application Program Compiler (RAPC) supports a few basic preprocessor directives. The directives can be used to take advantage of features available in later BlackBerry smartphones and builds without fragmenting into multiple code lines, or to make it easy to remove debug output for final versions.

The following directives are supported:

Enable the preprocessor
//#preprocess

If, else, end if block:
//#ifdef
…
//#else
…
//#endif

If is defined, then the code between #ifdef and else is executed; otherwise, #else to #endif is executed. The else section is not mandatory.

If not, else, end if block:
//#ifndef
…
//#else
…
//#endif

#ifndef is the opposite of #ifdef. If is not defined, the code is executed.

When using the BlackBerry JDE Plug-in for Eclipse or BlackBerry JDE 4.7 and later, you can set preprocessor defines in the Project Properties window, on the Compile tab as shown in the following image:

If the Preprocessor defines box is not present in Eclipse®, update the BlackBerry JDE Plug-in for Eclipse to the latest available version. If you have not configured Eclipse to use the BlackBerry JDE Plug-in for Eclipse update site, this can be accomplished by following the steps found at http://na.blackberry.com/eng/developers/javaappdev/javaeclipseplug.jsp.

To use the preprocessor in BlackBerry JDE prior to version 4.7, you must manually add it to the Java® development project (JDP) file. To do this, complete the following steps:

Open the JDP file with an editor.
Go to the line that starts with Options.
At the end of the line, add -define ;;…; as in the following example:
Options=-quiet -define=FOO;PREPROCESSOR
The -define statement is simply an argument passed to the RAPC. Therefore, you can use it with your own command line build scripts. This functionality has been present since RAPC version 4.0.
If you use the preprocessor, make sure at least one definition is defined, typically PREPROCESSOR, or it will not engage.

Check out AppJam: Only Apps >> Mobile Applications >> Demo of Mobile Apps >> Mobile Application Showcase event >> AppStores

Check out AppJam: Only Apps >> Mobile Applications >> Demo of Mobile Apps >> Mobile Application Showcase event >> AppStores

Advertising on iPhone

For the most part, ads on iPhone apps seem to mimic the formats we’ve come to know via more traditional online browsing on PCs. A relatively non-intrusive banner typically shows up at the top or bottom of the open screen. (I have yet to see an app that forces a “pre-roll” ad before the app runs)

However, with the relatively slow data transmission speeds we see on iPhones (even those lucky enough to enjoy consistent 3G connectivity) and a clunkier way of shuttling between different browser windows and applications (the iPhone does not allow apps to run in the background, so exiting an app to visit a Website will shut down the app), user engagement with ads is a far more disruptive event and much less likely to happen among those users who don’t want their workflow or play interrupted.

Branding opportunities remain, though, especially on a new platform where novelty of the medium commands users’ attention. And hypertargeted ads tailored so well to a user’s needs might also perform well enough to cross the “interruption chasm”.

There are already several ad network/platforms available for iPhone apps. Here’s the current list of offerings:

Crisp Wireless – currently creates banners + microsites; used by the New York Times and Washington Post apps

PurpleTalk – allows creation of customizable text banners; features ad exchange “Partner Network”

AppLoop – claims to be the first real-time, location-based mobile advertising network

Pinch Media – widely used ad network on dozens of iPhone apps

Medialets – offers CPM, CPC and CPA advertising run natively through iPhone apps

AdMob -offers rich-media (video-, map- and Apple App Store-integrated) banner ads on iPhone apps; also has an impressive list of signed clients

Application Advertising

    The following have specific iPhone application advertising solutions for those that have created iPhone applications and wish to earn revenue by placing advertising in their iPhone application. Some of the following advertising networks are exclusively iPhone applications and others have programs for iPhone applications as well as other publisher solutions.  

How do iPhone app ads work?

Although the solutions are different in terms of how they render in an app and what the engagement and payment models are, they typically comprise clickable banner ads, which either link to an iPhone-optimized microsite, a Web page, or, in the case of AdMob’s banners, even video, map or App Store integration.

For Revenue:

Medialets: Insert ads into your application using easy to drop in Objects, also track your users interaction with your application, earn a CPM.

AdMob: Offers ads for your iPhone using Javascript” code. AdMob has been around for a while and has publisher solutions for mobile phones, not just iPhone applications.

PinchMedia: Offers ads and analytics for your iPhone application, exclusively for iPhone applications.

For Ad Swapping:

PurpleTalk: PurpleTalk allows you to join an advertising exchange with other iPhone developers. You earn advertising views of an advertisement for your application when you advertise others. You do not make money with these ads however it is a free way to increase the adoption of your own application.

For Analytics:

PinchMedia: Offers analytics for your iPhone application, exclusively for iPhone applications.

As iPhone’s become more popular by the day, and applications become more widely used your application may become a nice revenue generator. Many options exist.

If you have a new application you could use the PurpleTalk code to gain free exposure and hope to increase your application adoption. Once you have gained adoption and increased usage you could add the advertising code from one of the above iPhone Publisher Networks and start earning revenue from your inventory.

Top 10 mistakes in iPhone App Development

Here are top 10 mistakes I’d encourage you to avoid.

#1 Creating an Overly Complex App

The first app we created at Pinger was called Pinger Phone. Although this app did get into the top 100 for a short while, its main flaw was that it was way too complex. It had both a social media feed and an IM client. Those who understood it, loved it. Buy many people just didn’t get it.

So when it comes to apps, keep it simple.

#2 Having a Paid Only Strategy

There may be certain apps that don’t work well with a lite version, but I suggest you have a free and paid version if possible. You get double the possible exposure in the app store and you let users try your app before spending money on it.

#3 Using Sub Par Graphics

Just look at the top 100 apps. Some of the icons look like I created them (that’s not a good thing). They are blurry, unprofessional, and don’t stand out. Create the best graphics that your budget allows.

#4 Flipping a Coin to Price your App

The app store is a bit of a garage sale with $.99 tags on many items. Before you just go with the $.99 price, do research. What are your competitor’s apps priced at? Better to price your app a bit high to start. You can always lower the price later. One exception to this is the app Ping! Great app and great strategy. It was free for the first couple days while he marketed it into the top 100. Then he made it $.99. His strategy worked.

So it’s not always one size fits all. Think it through.

#5 Having No or a Last Minute Marketing Plan

I talk to so many developers that start their marketing plan once their app has been approved. Big mistake. While you’re dreaming up your perfect app, you should make your marketing plans.

#6 Not Tracking Everything You Can

At a minimum track downloads, ranking, revenue, and important changes daily. You do this to see what is driving your downloads and what is not. If you get a great review in an app review website, did it drive more downloads? If you spend money on mobile ads, how did that impact your lite and paid downloads?

#7 Not Being Willing to Spend Money

You’ve spent hours and hours building a great app. You should be willing to spend some money to promote your app. I realize it could be a waste of your precious funds, but you may also have a hit on your hands that no one ever finds out about.

#8 Not Doing Keyword Research

Apple gives you 100 characters to enter keyword information about your app. Do your homework. Use Google’s free keyword tool and the iPhone app store search box to figure out what keywords to use.

#9 Not Using your Userbase

If you’ve got a userbase when you launch your first app, announce the app to them. If you don’t, create a way to register or message your users for future updates or other app launches. Happy users you can contact are invaluable.

#10 Not Becoming or Hiring a Marketer

You can’t just be a developer. You need to become a marketer. Either start learning on your own or hire someone who can help you.
In summary, hope this helps you avoid mistakes and have success in the app store!

APIs in J2ME

General APIs
The core APIs are defined by the underlying Connected Limited Device Configuration.

javax.microedition.io

Contains the Java ME-specific classes used for I/O operations.

javax.microedition.lcdui

Contains the Java ME-specific classes used for the GUI. LCDUI has a simple screen based approach where a single Displayable is always active at a time in the application user interface. LCDUI API provides a small set of displayables common in mobile device user interfaces: List, Alert, TextBox, Form and Canvas. For all displayables the device MIDP implementation has control over the presentation and layout of the displayable. Canvas is a low-level graphics surface for which an application has full control over what is rendered to it, although normally some space is reserved for system areas like screen title and indicators common in mobile device UIs. Since MIDP 2.0, Canvas also supports a full-screen mode that allows to make full screen graphics, which is especially useful for games.
LCDUI also has quite unique approach of abstract operations, called Commands. The placement of commands added to a displayable is completely up to the device implementation of this toolkit. The application programmer uses API specified command types to indicate the usage or purpose of the command in application user interface. Common types are BACK, EXIT, ITEM, SCREEN. The idea of the command abstraction is to make applications more portable between various different mobile device. Application developers should use the command types properly to indicate the purpose of an operation, and device implementation then places the operation to the common location for a given type in device's specific user interface style. This may be e.g. a specific key, like "a back navigation key" for BACK commands or button on screen.
The term LCDUI was actually a joke in JCP Expert Group that created it. It has not been opened up in the MIDP specifications but stands for Limited Capability Device User Interface. The joke was that no-one else really knows what it stands for. Then later the Programming Wireless Devices with the Java 2 Platform, Micro Edition book gave this term out.
Other common definitions have appeared. "Liquid Crystal Display User Interface" would reflect the fact that mobile phones normally use LCD displays; however, the API is not specifically tailored to this particular display technology. It is also said that "LCD UI" stands for "lowest common denominator" due to the fact the specific UI has simplest possible design.

javax.microedition.rms

Provides a form of persistent storage for Java ME. It's like a database for the mobile device.
"Record Store"(class) is used to store the Data: RecordEnumeration(Interface) , RecordComparator(Interface), RecordFilter(Interface), are used to apply user queries for sorting,filtering the data of all the data present; and comparison of contents of two or more RecordStores is done by these Interfaces.Data is stored and must be retrieved from the RecordStore using a ByteArray.(i.e; data is stored in Bytes(string.getBytes() and stored in ByteArray Byte a[])

javax.microedition.midlet

Contains the base classes for Java ME applications.

Specialized APIs added in MIDP 2.0

MIDP 2.0 saw the introduction of gaming and multimedia APIs and some optional packages.

javax.microedition.media

Contains the base classes of the multimedia playback. These are approximately a subset of the JSR 135 Java Mobile Media API.

javax.microedition.lcdui.game

A gaming API aimed at simple 2D sprite based games.

javax.microedition.pki

Authenticate APIs for secure connections.

Optional JSRs

The following JSRs are not part of MIDP (1.0 or 2.0) but provide extra functionalities on some handsets. However, there is no guarantee that a MIDP2.0 handset implement such APIs

javax.microedition.messaging

Wireless messaging API (optional), for sending SMS and MMS messages.

javax.microedition.pim

Personal information management API (optional), access the device's Address Book , to-do List, Calendar.

javax.microedition.io.file

The File Connection Optional Package (FCOP) is one of two optional packages defined by JSR 75 through the Java Community Process. The FileConnection API specified in JSR 75 gives access to the local file systems on devices like PDA. In order to overcome security issues MIDlet needs to include requested file permission in its JAD file under MIDLet-Permission property.

Development Tools

There are several different ways to create MIDP applications: Code can be written in a plain text editor, or you can use a more advanced IDE such as NetBeans, IntelliJ (with bundled Java ME plugin), or Eclipse (with plugins such as EclipseME) which has a user interface for graphically laying out any forms you create, as well as providing many other advanced features not available in a simple text editor.

Noteworthy Limitations of MIDP 1.0

• MIDP 1.0 has no active rendering APIs
  
• MIDP 1.0 has no support for direct access to image pixels (RGB data)
  
• MIDP 1.0 has no support for full screen mode
  
• MIDP 1.0 has no support for audio
  
• MIDP 1.0 requires only HTTP support
  
• MIDP 1.0 cannot query key status (although key events are supported)
  
• The specifications are not always clear, leading to differences in implementations
  
• Some limitations may be avoided by using a vendor-specific API or MIDP 2.0, which obviously reduces the portability of the application