'Small World' shows iPad capability for board games

The iPad remains a gaming device with a lot of unrealized potential.

The large screen and touch controls allow for many gameplay options, including board games.

We were sent a review code for "Small World," and after checking it out, we're of the mind that the iPad can handle the genre quite well.

"Small World" is a French board game that sees different races spreading across a fantasy land, holding onto as much territory as possible without overextending their forces. It may seem a little tricky at first, and the in-game tutorial and instructions leave a little to be desired, but you'll pick up the rules in no time.

If you need extra help, more information is easily found online; the physical copy of the board game has been written about extensively.

There are unfortunately some major holes here. There is no online play, and no AI opponent to hone your skills against. You'll need another human player to compete against, and you can sit across from your opponent or trade the iPad back and forth.

While online play would have been nice, asking $5 for what amounts to a digital version of the board game is more than fair. The real thing would have been $30 or more.

There is no way to lose pieces, and you can easily play the game in a car or on a plane. I've been having a good time with it, and I hope more European-style board games make the jump over to the iPad. If there was a premium version released for $10 or more that included online play or computer-controlled opponents, it would be worth an upgrade.

One of my favorite iPad apps is Game Table, which simply offers digital versions of checkers, chess, reversi, and poker. For a dollar, that's quite the deal, and I've often challenged the kids to a game when we're bored in the car.

Seeing more complicated board games make the jump to the iPad this inexpensively is a good thing, and we hope to see more of it in the future.

What to expect from Apple's iPhone-centric WWDC

News outlets may have spoiled the big surprise for Apple's upcoming Worldwide Developers Conference by publishing early photos and details of the next-generation iPhone. Nonetheless, in a recent e-mail, Steve Jobs promised a customer that "You won't be disappointed" by the announcements to come.

What else might Apple have in store for the event, which happens June 7 to 11 at San Francisco's Moscone Center? Before last year's WWDC, Wired.com accurately predicted the introduction of new iPhones and MacBooks, as well as the release date of the Snow Leopard operating system.

So with this year's WWDC keynote scheduled for June 7, we thought it'd be fun to step up and place our bets once again.

In addition to the obvious new iPhone, we're predicting something big happening with relation to streaming video.

Also, we dismiss recent rumors about Microsoft making an appearance to announce iPhone OS developer tools, and once again we file the possibility of a Verizon iPhone under "unlikely."

The Next iPhone

Gizmodo and a Vietnamese blog appear to have spilled all the beans about the next-gen iPhone: an aluminum chassis, a thinner case, a front-facing camera, a higher-resolution screen and a camera flash.

It's important to note that Apple legal confirmed in an unsealed affidavit that Gizmodo's prototype represented the fourth-generation iPhone, so there's no longer need to speculate about whether this really is Apple's next smartphone: It is.

However, both Gizmodo and the Vietnamese blog were unable to demonstrate their prototypes actually doing anything, so plenty of questions still remain.

We think the highlight feature of the 4G iPhone will be the front-facing video camera. How will video conferencing with a front-facing camera work in terms of bandwidth? AT&T has acknowledged its 3G network is overloaded by traffic coming from smartphones (especially iPhones), and plenty of people have issues just making phone calls or surfing the web.

Also, think beyond 4G iPhone owners video-conferencing with other 4G iPhone owners. We predict 4G iPhone owners will be able to video chat with iChat users with webcams on their Macs. Corroborating our theory, already there are clues in developer releases of iPhone OS 4.0 that there will beiChat support in the next iPhone.

Meanwhile, it's quite possible that Apple will have something to say about one-way video streaming. Perhaps Apple will finally put to use its massive data center, which could provide the bandwidth required for ubiquitous video feeds of movies, short video clips and more.

We speculated in December that streaming video may eventually play a key role in Apple's future of personal media. After all, Apple's acquisition of Lala suggests the company is interested in turning iTunes into a streaming music service, and adding live video would turn iTunes into a personal media hub.

One big question remaining is the back of the iPhone. Neither Gizmodo nor the Vietnamese blog were able to confirm the exact material, but they described it as a glasslike plastic. Here's the kicker: An analyst said in January that he'd heard Apple's next iPhone would feature a touch-sensitive housing similar to that seen on Apple's multitouch Magic Mouse. We're willing to guess the next iPhone's back will detect multitouch gestures so you can control core features such as the music player while the device is still inside your pocket.

We would expect the next iPhone to ship sometime in June. (Apple announced its iPhone 3GS during WWDC on June 8, 2009 and began shipping it 11 days later.) A likely name? Engadget has heard iPhone HD, and we're into it.

iPhone OS 4

Apple already previewed iPhone OS 4 in March, but only a few key features multitasking, universal e-mail and the ability to create folders, among others were highlighted. Expect the full story at WWDC. The latest beta releases have already revealed clues about unannounced features, such as a new widget interface for the iPhone's music player, tethering for AT&T customers, and file sharing with your PC.

In addition to getting the full details on iPhone OS 4, expect a release date possibly as soon as the day of the keynote. Apple has said iPhone OS 4 is due for release in the summer for iPhones and iPod Touch devices, and in the fall for the iPad.

(Do note if you own an original iPhone or first-generation iPod Touch, you're out of luck: iPhone OS 4 will only be compatible with the second- and third-generation models of each device -- and presumably the next-gen iPhone, too, of course.)

No Steve Ballmer or Silverlight

Developers and analysts are buzzing about a rumor that Microsoft's Steve Ballmer will take the stage at WWDC to announce its own third-party developer tools (possibly Silverlight) for making iPhone and iPad apps. That sentence already sounds ludicrous considering that Jobs, in an open letter explaining why Flash isn't allowed on the iPhone OS, made it crystal clear he didn't want meta platforms participating because they would result in sub-par apps.

Wired.com phoned the analyst who made that prediction, Trip Chowdry, and he told us that he based his prediction on speculation from mobile developers, not hard evidence.

Indeed, Microsoft announced on Twitter that Ballmer was not making an appearance at WWDC, so consider the "rumor" debunked.

No Verizon iPhone

Along with angry AT&T customers, Verizon subscribers aching for an iPhone have been hopeful that Apple will share its next iPhone with Verizon. Don't bet on it happening at WWDC. The most credible rumor report, published by The Wall Street Journal, claims a CDMA iPhone is scheduled for mass production in September.

Expect a Verizon iPhone no sooner than then, though we would lean toward the conservative side in guessing that such a device won't see the light of day until 2011.

Man Infects Himself with (Computer) Virus

We are one step closer to the future: a British scientist has become the first human being to contract a computer virus.

Yep, you heard that right. Dr. Mark Gasson, a cybernetics expert at the University of Reading, deliberately infected himself (by way of an RFID chip implanted in his wrist) with a benign computer virus. This was part of an experiment designed to show how implantable bionic devices are susceptible to computer viruses.


The device in Gasson's arm is an RFID (radio-frequency identification) chip that emits a signal and allows him to access certain parts of the University of Reading laboratory, as well as operate his cell phone. In other words, the chip functions as an internal swipe-card.



Gasson and his colleagues then created a virus for the chip. They put it on the chip and Gasson went into the lab--and when the lab's computers read the code, the virus implanted itself into the database and began to replicate. Now if any of his other colleagues swipe their traditional swipe-cards to get into the lab, the virus can replicate itself on their swipe-cards.

This experiment shows that viruses can be transferred wirelessly from implant devices to the computers they communicate with. Someone could thus potentially create a virus that would allow them to access secure areas (such as the University of Reading laboratory).

This is not the first instance of an RFID system being hacked--but it is the first time that the hacked RFID chip was inside a human being.

Now, while a computer virus in Gasson's arm won't affect his health--that's not the case for a lot of other people with bionic implants. People with pacemakers, cochlear implants (for the hearing-impaired), and deep brain stimulators (for neurological conditions), for example, could be in big trouble if a virus infected their implanted devices.

"I don’t think for us that (infectious technological agents) would be a particularly new concept, but implants in our bodies will make it a lot more real," Gasson told TechNewsDaily, "A denial-of-service attack on a pacemaker, if such a thing were possible, would of course be very detrimental."

In the future, bionic implants may not only be for cool scientists like Gasson or people with medical conditions--people may eventually use implants to improve brain function, memory, and IQ.

Video Memory Programming in Text Mode

Nowadays we take so many things for granted. This isn't necessarily a bad thing, as knowing that performing a certain task will usually yield the same result can be a blessing. Nevertheless, some basic knowledge of how a thing gets done lets you better understand the world in which we live. Therefore, today I invite anyone who likes to code in any of the popular languages to see how a word gets printed out on the console screen.

Any half respectable book that tries to describe a new programming language starts with this. Let us print a sentence on the screen. The classic one is "Hello World!" of course, but some like to spice things up and use a more elaborate example. To get the text on the screen, most of the time you just call a function that will take care of the rest.

However, getting any information on the screen isn't as simple for the operating system. Remember that an operating system needs to work on multiple types of hardware configurations, and the way that some information gets from the system memory to display some colors on your screen varies. To make life simpler for the OS and to avoid design chaos, some basic rules have been established that all hardware manufacturers follow at some level.

The actual job of drawing something to the screen always falls to the video card. It has to carry the input data to your screen. Now we cannot assure a real time procession, as a sudden data burst may overload our bandwidth no matter how large that is. Therefore, all video cards have, at some level, some memory for their own usage.

This memory also allows them to store data that they need frequently. Doing this relieves some pressure from the CPU, as recurring data needs to be transferred to the video card only once. If you are interested in how a CPU works in detail, I invite you to look up the article series I dedicated to this in my profile. Besides the technical description, I created a simple demo sketch of my words using the VHDL language.

Returning to the video card, the device itself will in the future take care of getting the information from its memory to the screen. Think of this task as turning on or off a given color channel of the monitor at a given point on the screen, based on whether the value of a predetermined memory bit is zero or one. With this approach, all that the OS needs to do is copy the correct information from the system memory to a predetermined zone of the video card.

Please keep in mind that this is a really simplified view; there are a couple of limitations when implementing this in the real world that complicate the proper execution. Nevertheless, this explanation will allow you to get the basic idea. A video card has multiple modes. Some of them, in order to assure better performance, will probably do things a little differently from the way I described on the previous page. However, there exist a number of modes that all video cards know: EGA, VGA, and SVGA. In the text to follow, we will work on the latter.

Where to copy

The standard printing functions are slow. Most of the time this is because they perform multiple security checks, and because they are capable of executing some complex tasks (like printing both integer and double numbers and text). However, whenever we want to perform a fast print to the screen, we want to bypass all this. The solution is to copy the data from the system memory to the graphic card's memory ourselves.

The structure of the video card's memory depends on the mode it is running and the video card itself. In order to somehow bypass incompatibilities, there exist some standardized modes that all video cards can run. SVGA is just one of these, and while you run in this mode, the structure of all video cards will be the same regardless of whether the subject is a 10-year-old card or a brand new one just rolled out on the doors of NVidia or ATI.

The SVGA mode is a text-based console window that can print out 80 characters in a row and has 25 rows. The address of the used memory in this mode starts at 0XB800 with the offset of 0X000. Starting from this point, for every character on the screen we have two corresponding bytes, one after another.

The first holds the character itself (coded in the ASCI) and the second is the attribute byte. This tells to the video card how to draw out the character found in the first byte. I have have depicted the structure of this in the following image.

The coding used is the RGB channel (Red Green Blue). Every color comes out of the combination, at some level, of these colors. We have one bit for each channel that shows whether that color is mixed in into the resulting color, and a fourth bit (the I character in the picture above) is an intensity bit. If it is on, the color is brighter; if not, a darker style of the color appears on the screen.

The bits on 6,5,4 communicate the background color for that character. The seventh bit is the blink bit. If this is on, the text will blink, just like the cursor does in a Word document. The character set used, and the font, depend on the selected table. This is a table that the video card stores in a ROM or RAM memory of 256 elements (one for each ASCI code). If it is in the RAM, the user can modify it.

You can change the font and the colors used with some Bios functions of the video card. The default values are characters that are 9 X 16 pixels in size. The primary character set (up to the 127^th ASCI code) is at the address 0XF000 to 0XFA6E. The rest of the character set is at the address returned by the break vector 0X1F. We will describe break vectors in a future article.

The current operating systems do not allow this kind of low level access to the video card. In order to allow this, we need to use an environment that grants us that access. The Turbo C or the Borland C 3.1 development IDE allow this. First you will need to acquire such a thing. A few Google searches should definitely reveal a couple of sources. Furthermore, these are 16-bit programs.

The code

Because the Windows operating system's backward compatibility is only one step long, you cannot run these programs on a 64-bit operating system. If you are in this situation, to try out this code you will need to install a 32-bit operating system. In order to make the task of installing a new operating system a little easier, you may use a virtualization method like the one presented by the VMware Player or the Windows virtualization system.

Once you have a development environment like the Borland Turbo C++ 3.0 up and running, you can create a new file and use the pokeb function to write data to the video memory. Defined in the dos.h header, this function will store a byte value at the memory location and the offset specified. With the following formula: (80*y+x)*2 we can calculate the offset of a character in row y and column x. Now we can start up and just use the following code:

#include

#include

#include

#include

#include

typedef unsigned int uint;

typedef unsigned char uchar;

void clear () // clear the screen -> black bg and fg

{

uint x, y;

uint offset;

for (x=0; x<80;>

for (y=0; y<25;>

{

offset = (80*y + x)*2;

pokeb (0xB800, offset, 0);

pokeb (0xB800, offset+1, 0);

}

}

// Put a character in the x-th row y-th column

// The attributes are inside a and the character is c

void putXY (uint x, uint y, uchar c, uchar a)

{

uint offset;

if (x<80>

{

offset = (80*y + x)*2;

pokeb (0xB800, offset, c);

pokeb (0xB800, offset+1, a);

}

}

// Put the text(s) in l-th row with attributes a

void putLine (uint l, uchar *s, uchar a)

{

uint i;

for (i=0; s[i]; ++i)

putXY (i, l, s[i], a);

}

//Print a file text. Attributes are random. Stop per screen.

void putFileText (char *fname)

{

FILE *f;

char s [80];

uint l;

uchar a=15;

randomize (); // to get truly random attributes

f = fopen (fname, "r"); // open file

if (f == NULL)

return;

for (l=0; !feof (f); ++l) // until we have from file

{

do {// avoid same foreground and background colors

a = random (256);

} while ((a & 0XF0)>>4 == (a & 0X0F));

fgets(s, 80, f); //get item and print

putLine (l, (uchar*) s, a);

if (l==24) // when the screen is full, clear and wait

{

getch ();

clear ();

l=-1; //reset to start

}

}

fclose (f); //close the file

}

//Fill the background with the attribute, use space chars

void fillBackground (uchar a)

{

uint x, y;

uint offset;

for (x=0; x<80;>

for (y=0; y<25;>

{

offset = (80*y + x)*2;

pokeb (0xB800, offset, ' ');

pokeb (0xB800, offset+1, a);

}

}

// Fill the screen with zeros

void fillForeground (uchar a)

{

uint x, y;

uint offset;

for (x=0; x<80;>

for (y=0; y<25;>

{

offset = (80*y + x)*2;

pokeb (0xB800, offset, '0');

pokeb (0xB800, offset+1, a);

}

}

// construct an attribute byte based on the input

uchar setAttributes (uchar Bi, uchar Br, uchar Bg, uchar Bb,

uchar i, uchar r, uchar g, uchar b)

{

uchar a=0;

a |= (Bi&1) <<7;

a |= (Br&1) <<6;

a |= (Bg&1) <<5;

a |= (Bb&1) <<4;

a |= (i&1) <<3;

a |= (r&1) <<2;

a |= (g&1) <<1;

a |= (b&1) <<0;

return a;

}

// merge predetermined background and foreground colors

uchar setBackgroundForegound (uchar B, uchar F)

{

uchar a=0;

a |= (B&0xF) <<4;

a |= (F&0xF) <<0;

return a;

}

//The main entry point of the program

int main ()

{ //set SVGA text mode

uchar a;

textmode (3);

clear ();

// Using a yellow char color and dark red background

// print letter a at 0 0

a = setAttributes (1, 1, 0, 0, 1, 0, 1, 0);

putXY (0, 0,'a', a);

//at 39 12 put a white background

a = setBackgroundForegound (0, 4);

putXY (39, 12, 13, a);

getch (); //wait for user input

//clear the screen and wait for user input

clear ();

getch ();

//Black background, red letters print the command code

fillBackground (setBackgroundForegound (7, 10));

putFileText (

"C:Archit~1Archit~1Archit~1Video ext.cpp");

getch (); //wait for user input

textmode (LASTMODE); //reset the previously used text mode

return 0;

}

The code snippet on the previous page will deliver first a letter in the upper left corner, and a music key in the center of the screen.

What do we have in the end?

For the clean screen I will not post an image (surely you can imagine a black screen), however, the printing out of the code file itself is worth a couple of comments. The file name you need to use is the one the IDE itself sees. The long folder and file names are cut off and replaced with some numbers at the end, as you can see in my example.

The background color we set previously will appear only the first time, because afterward I use the clear function I wrote to clear previous information off of the screen, and this also resets the background color. Nevertheless, you are free to write a custom clear function that may skip writing to the locations specifying the background color. Using the peekb function to read out the previous background color and set it again after clearing it is also an option. I will leave these to you.

Next time we meet I will show you how to write to the video memory using the graphic mode. This will leave you the option of printing blazing fast lines, rectangles and circles on the user's screen. Until that you may post questions you have here on the blog following the article or join the DevHardware community. Live With Passion!

Developing Applications for the BlackBerry Smartphone

Learn how easy this process is using Oracle JDeveloper and Oracle ADF

by Luc Bors

Published May 2010

Oracle Application Development Framework (Oracle ADF) offers a complete framework (design time and runtime) for BlackBerry smartphones that supports two types of mobile applications: Oracle ADF Mobile Browser applications, which function as a connected Web application running in the BlackBerry browser (these applications can also be customized and optimized to run in that browser); and Oracle ADF Mobile Client applications, which are running in disconnected mode on the mobile device leveraging device-native UI components. In either case, the development process is the same. In this article, you will learn how easy this process is using Oracle JDeveloper and Oracle ADF.

Developing a Basic Mobile Browser Application

Developing mobile browser applications for mobile devices with Oracle ADF Mobile Browser client leverages the same methodologies used in developing JSF applications for the desktop, with the addition of a few specific mobile extensions. Thanks to support in the client for over 60 Apache MyFaces Trinidad components, you can build applications with a rich component set, each of which renders appropriately for small-screen mobile devices. In this manner, you can reuse the desktop browser application's model and controller layers to assemble a new view layer for mobile devices. Thus, the process of developing a basic mobile browser application is not much different from that of developing a Fusion Web application in Oracle JDeveloper. (All steps to create a basic Oracle ADF Mobile Browser Application are described here.)

The Trinidad mobile renderers have been optimized to minimize the payload of the Web page sent to the mobile device for improved performance over wireless networks. In mobile environments with high-latency and low-bandwidth wireless networks, Partial Page Rendering (PPR) is essential in providing end-users with an efficient application. For mobile browsers supporting Ajax, Oracle ADF Mobile browser client supports PPR for certain components to minimize the amount of data requested from the server and improve the responsiveness of the applications.

Oracle ADF Mobile Browser client has the ability to render applications to older and newer BlackBerry browsers. When using versions before 4.6, you have to take in account that some features are not supported.

Browser	Javascript Support	CSS Support	PPR Support
BlackBerry version 4.6 and later	Yes	Yes	Yes
Blackberry versions 4.2 through 4.5	No	Yes	No

Table 1 Supported Browsers and Supported Mobile Features

For example, on browsers for BlackBerry 4.5 and earlier, the bullets in a list sublevel (such as those in a tr:panelList component) appear abnormally large. The BlackBerry browser’s table handling may affect complex layouts; the BlackBerry browser does not allow horizontal scrolling. Instead, it wraps a table row onto multiple display lines which may disturb the layout.

Although Javascript is not delivered to the older BlackBerry browsers, the mobile renderer will deliver plain HTML content to BlackBerry browsers 4.2 to 4.5..

Chapter 6 in the “Mobile Browser Client Developer's Guide for Oracle Application Development Framework” goes in to the specifics of how to accommodate the behavior of RIM BlackBerry browsers 4.2 to 4.5.

Optimizing an Oracle ADF Mobile Browser Application for BlackBerry

Although the application you create when following these steps is optimized for running in Mobile Browsers, it is not yet optimized to render optimally in a BlackBerry browser.

Mobile Browser Application

What you will see is that the look and feel is not even close to that you would expect to see on a BlackBerry device. Also the user experience is not yet optimal. However, there are some steps you can take to ensure a “real” BlackBerry experience.

Skinning One of the steps to optimize the user experience is to use skinning. Skinning allows an Oracle ADF Mobile Browser application to deliver a BlackBerry-optimized user interface using Trinidad components. It also allows the same set of UI components to take on a look-and-feel optimized for BlackBerry smartphones, without needing to create multiple versions of the same application for different mobile devices. To have the application use a blackberry skin, it must be configured to do so.

The first step in skinning for BlackBerry is to implement logic that would allow a JSF application to apply different style sheets for different mobile browsers during run time. Because 4.2-4.5 browsers get the plain HTML content, which changes the page layout, you may want to use different CSS for 4.2-4.5 and 4.6+ browsers. To support that, you need to find out the actual device type that the application is running on. This information is available from within the request.

In the trinidad-config.xml file you can set the element to determine which skin to use. For that you can use the EL expression #{requestContext.agent.skinFamilyType}. This would return blackberryminimal for 4.2 to 4.5 browsers, and blackberry for 4.6 (i.e. JS enabled) browsers.

 #{requestContext.agent.skinFamilyType} 
 

You have to create the various skin families in the trinidad-skin file, as well as the corresponding location of the CSS file within the project. If there is a skin family that’s not listed in the trinidad-skin file, then Oracle ADF will just deliver the default skin file. The entries for BlackBerry would be:

       blackberry4_2
      blackberryminimal
       org.apache.myfaces.trinidad.pda
      styles/blackberry4_2.css
  

     blackberry4_6
blackberry
org.apache.myfaces.trinidad.pda
styles/blackberry4_6.css
   

Besides skinning, Oracle ADF provides framework features that help developers to create applications that are optimized for BlackBerry browsers. As you might know, the BlackBerry browser behaves differently than many other browsers in that it does not display pages using horizontal scrolling. Instead, it fits a page to the width of the screen.

Optimizing Browser Page Layout. In order to create an optimal layout for the BlackBerry you can use styleClasses. These styleClasses can be set in the styleClass property of the components on the page. You can for instance create a typical BlackBerry toolbar for the application, just like the one below.

BlackBerry Browser Look and Feel

                                      text="Back"
                           action="back"/>           
                                      text="Sign Off"            
                           action="signoff"/>

These styleClasses have to be defined in the stylesheet associated with the skin you use. The af_m_button in the code fragment above is defined like this:

.af_m_toolbar .af_m_button {
 position: absolute;
 right: 10px;
 text-align: center;
 vertical-align: middle;
 text-decoration: none;
 padding: 5px 0px;
 width: 70px;
 height: 25px;
 overflow: hidden;
 border-width: 0px;
 font-size: 13px;
 font-weight: bold;
 color: #FFFFFF;
 background: url(/images/toolButton.png) no-repeat transparent;
 white-space: nowrap;
}

If all the styles are defined properly, and applied to the components in the correct way, you can achieve a BlackBerry look and feel.

Optimized Mobile Browser Application

Server-Side integration with BlackBerry Enterprise Servers.The BlackBerry Enterprise Server is designed to be a secure, centralized link between an organization's wireless network, applications, and BlackBerry devices. This involves functionality such as messaging and collaboration software and custom applications, to provide BlackBerry device users with mobile access to your organization's resources. Oracle ADF Mobile Client integrates with the BlackBerry Enterprise Server.

For device management and application provisioning, Oracle ADF Mobile Client can also leverage device-native management solution such as BlackBerry Enterprise Server, allowing IT administrators to use the existing toolset to manage an Oracle ADF Mobile Client application. BlackBerry Enterprise Server v5.0 features built-in over the air software loading which simplifies wireless deployment of BlackBerry smartphone software. (For more details and examples on BlackBerry Enterprise Server go to the BlackBerry Developer site.)

Developing BlackBerry-Native Applications Using Oracle ADF Mobile Client

Oracle ADF Mobile Client is a mobile implementation of the Oracle ADF Model-View-Controller architecture that lets you build an on-device, native mobile application for the BlackBerry smartphone. For scenarios where there is a need for deep integration with the capabilities of the mobile device, or to work in a disconnected mode, Oracle ADF Mobile Client is the appropriated development approach.

Oracle ADF Mobile Client consists of a client part that includes a mobile Model, Controller, View, and J2ME runtime. There’s also a Model that includes the local relational database and the mobile BC4J layer as shown in Figure 4.

Oracle ADF Mobile Client Architecture

The Oracle ADF Mobile Client’s Model-View-Controller stack resides on the BlackBerry device and represents reimplementation of Oracle ADF’s model-view-controller layers. UI metadata is rendered to native components on-device and is bound to the model through JSR 227.

Figure 5 shows how the runtime architecture for Oracle ADF Mobile Client Applications fits in the overall architecture (on the right in red).

Oracle ADF Mobile Client Architecture

The application infrastructure for Oracle ADF Mobile Client Applications is shown in Figure 6.

Oracle ADF Mobile Application Client Architecture

The Oracle Lite Mobile Server is used to manage synchronization to the server database.

Oracle ADF Mobile Client Support for BlackBerry Smartphones

Oracle ADF Mobile Client offers full support to run on BlackBerry smartphones from version 5.0 or above. You can deploy Oracle ADF Mobile Client runtime from within JDeveloper by selecting the tools - Deploy Oracle ADF Mobile Client Runtime - menu item in Oracle JDeveloper.

Deploy Oracle ADF Mobile Client Runtime

When deploying the Oracle ADF Mobile Client Runtime to the BlackBerry device, a couple of files are copied to the device. These are COD files, which are file extensions for Blackberry libraries.

Deployed Files

These libraries are responsible for implementing the Oracle ADF Mobile Client framework functionality such as Oracle ADF model and Oracle ADF databinding, as well as the Oracle ADF User interface. There is also a library containing utility classes and some XML functionality, and finally the synchronization support and the on device SQLite database implementation.

Developing an Oracle ADF Mobile Client for BlackBerry, Step by Step

Developing an Oracle ADF Mobile Client application would usually involve the following steps:

• Create an Oracle ADF library for Business Components (when you are extending a server-side Oracle ADF application to mobile).
• Create a new Oracle ADF Mobile Client Application workspace in JDeveloper.
• Create Oracle ADF Mobile Client Businesses Components.
• Create the Oracle ADF Mobile Client User Interface.
  • Define the mobile taskflow
  • Create Mobile Application Pages
  • Define Mobile Application Menus
• Deploy the Application
• (Optional) Setting up Data synchronization

Before you can start you need to download and install the required software.

• Oracle Database (Standard or Enterprise)
• Oracle JDeveloper 11g Patchset2 (version 11.1.1.3.0) or later
• BlackBerry Java Development Environment (5.0 and later)
• BlackBerry simulator (version 5.0, build 442 or later)
• Request signature key at http://na.blackberry.com/eng/developers/javaappdev/codekeys.jsp

Optional Downloads:

• Oracle Lite Mobile Server and Mobile Workbench (needed only when testing data synchronization)
• Sample application and database files

Step 1: Create Oracle ADF Library For Business Components

The typical development scenario is to extend a “base” Oracle ADF application. Before you create the client application, the business components of the base Oracle ADF application have to be deployed to an Oracle ADF library. This library will be the base for the mobile client business components.

For that we have to create a new deployment profile, an Oracle ADF Library JAR file.

Create Deployment Profile

With the deployment profile in place, now deploy the business components project to an Oracle ADF library.

Deploy to Oracle ADF Library

Step 2: Create a New Application Workspace

The Oracle ADF library containing the base applications business components will be the base for the Oracle ADF Mobile Client Application.

An Oracle ADF Mobile Client application can be developed in Oracle JDeveloper using the Oracle ADF framework. The first thing you need to do is to download the Oracle ADF Mobile Client extension. To download this extension, go to Help > Check for Updates in JDeveloper. The extension can be found under Official Oracle Extensions.

Download extension

After installing the extension, Oracle JDeveloper needs to be restarted.

With the extension installed you will notice that there are some new options in the New….. gallery. The one needed is Mobile Client Application (Oracle ADF).

New Mobile Client Application

This will create an application workspace contains of an empty model project and a preconfigured Mobile Client project. The first will contain the business components in the final application; the latter will contain page flows and the Mobile Client interface.

Application Content

Step 3: Create Default Business Components

The next step in the development process is to create business components.

For version 1 of the Oracle ADF mobile client there are some limitations to the functionality of business components in comparison to standard Oracle ADF business components. While developing an Oracle ADF Mobile Client application you have to keep this in mind:

• Client Entity Objects are copies of a subset of the Entity Objects of the Base Application.
• View Objects must be based on Entity Objects or be static VO.
• Subset of EO and VO functionality is supported.

Also be careful when defining a VO based on a SQL statement. Only use the tables and fields available on the mobile device. When you define a SQL based VO, Oracle JDeveloper actually checks against the server database, and not against the client database, because client database is not there yet. Be careful not to pick objects that are not brought down to the mobile database.

Open the New Gallery and create new Oracle ADF Mobile Client Business Components from Entity Objects.

New Oracle ADF Mobile Client BC from EO

In the wizard find the appropriate Oracle ADFLibrary (the one that contains the Business Components from the Base Application) by using the Browse… button. Once you found the Oracle ADFLibrary, use the Import… button to import all the Entity Objects from the Oracle ADFLibrary into the Mobile Client Project. You can shuttle all the necessary entity objects from “Available:” to “Selected:”.

Select Entity Objects to use

Once the necessary entity objects have been selected, click next to go to the next page of the wizard.

Click next on page 2 of the wizard, and on page 3 select all available objects and shuttle them from available to selected, in order to create updatable view objects for all of them. Click Finish to close the wizard. The default model project for the mobile client application is now ready.

Step 4: Design the Taskflow and Pages

When the Oracle ADF Mobile Client Application was initially created, Oracle JDeveloper also created an empty MobileClient-taskflow file in the mobile client project. This taskflow can be used to design the page flow for the mobile client application. The taskflow editor can be opened by double clicking the file. The activities can be created by dragging them from the component palette to the taskflow diagram. It works exactly the same as when developing a standard Oracle ADF Application. There are a few limitations to keep in mind though. By default only one task flow per application is supported, and you cannot create multiple task flows and embed one within another. Page fragments are also not supported.

The taskflow editor supports wildcards, routers, method calls and taskflow returns.

The sample application in this article uses a home page as a landing page for the application. There will be the possibility to browse Personal data on the BrowsePerson page, and the application supports browsing and editing orders. A wildcard activity is added to go to the home page from anywhere and another one to support exiting the application from anywhere. The exclamation marks in the diagram indicate that the corresponding pages are not yet created, but they will disappear as soon as they are.

Taskflow Overview

You can create the pages from within the taskflow diagram. Create the empty home page by double clicking it. A popup appears where the page can be given a name. By default the name is the same as the activity name in the taskflow.

Create Pages

Notice the extension of the page being mcx. In an Oracle ADF Mobile Browser Application the extension of the page files is jspx. So the mcx extension is typical for Oracle ADF Mobile Client Applications.

Continue creating default pages for the remaining view activities in a similar way.

Step 5: Adding Databound UI Components to the Pages

You can create databound UI components in an MCX view by dragging data controls from the Data Control panel and dropping them into either the Structure window or the code editor. When you drag an item from the Data Controls panel to either of these places, Oracle JDeveloper invokes a context menu of the default UI component available for the item that you dropped. Oracle JDeveloper generates the mappings that determine which controls can be inserted into an MCX page. In addition, the IDE creates the binding information in the associated page definition file. If no such file exists, then Oracle JDeveloper creates one. The UI components are bound to the model through JSR 227.

The basic development process of a databound user interface is demonstrated by adding components to the BrowsePerson page. The BrowsePerson page is a databound page that gets its information from the Person collection. Select the PersonsView1 Collection in the datacontrol palette and drag it onto the BrowsePerson pages structure window. In the context menu that appears select Forms…Read-only Form….

Create Read Only Form

An edit form field dialog is invoked where you can make a selection of all available attributes. Delete some of the attributes as not all will be used in the BrowsePerson page. Make sure to check the “include navigation buttons” checkbox. This will add buttons to the page to browse to next, previous, first and last records. A submit button is not needed, as this is a read only page.

Edit Form Fields

That is all you need to do to create you first basic Oracle ADF Mobile Client page.

Step 6: Creating Buttons And Menus

The landing page of the application will be the “homepage”. To make “all” the other pages in the application available from within that “homepage” you need to add some navigation components to the home page. Start with adding the first button on the “homepage”. This button will be used to invoke the navigation activities that were defined on the taskflow, in the case the button will navigate to the BrowsePerson page.

Insert Buttons

After the button is created open the property inspector for the button. In the property inspector select the action attribute and select the appropriate action form the dropdown list. In this case the action is “b-Per”.

Edit Action Property

When the user pushes the button in the application navigation to the browsePerson page will be invoked. Add buttons for all other navigations on the “homepage” in a similar way.

It would be very convenient if these actions could be invoked from the BlackBerry main menu as well. In order to achieve this you simply add Command Menu Items to the page. Command Menu Items are action components as well and can invoke navigation. They can be added in the same way as the buttons that were added before.

Step 7: Creating Browse and Edit Order Pages

The final step in developing this demo Oracle ADF Mobile Client Application is to finish the two pages for browsing and editing orders. These pages are already created but still empty. The first page to take on is the browseOrders page. Drop the Orders1View1 from the datacontrol on the structure window and select read-only table form the popup menu.

Create Read Only Table

In the Edit Table Columns delete all items that are not to be included on the browseOrders page..

Edit Table Columns

Because navigation to the editOrders page is required, there is a need for a navigation component. This can be achieved by converting the orderId textfield to a commandlink that invokes navigation to the edit orderPage. In the sourceView tab of the page editor this can be achieved. Make sure the action points to “e-Ord”..

                          action="e-Ord"
                          id="outputText1"/>  

Finally create the editOrders page by dropping the order collection as a form. In the Oracle ADF Mobile Client Application there will only be a few changeable items. In this case only the items selected in the image below are editable. Remove all others.

Edit Form Fields

An order without it’s order lines is not very interesting. To add some more information to the order you can add the order lines as a detail table for the order form. Select the OrderItems1View2 collection in the data control palette and drop it on the editOrders page. Make sure to select the correct order item collection (i.e. the child collection of the Orders1View1). This will automatically display the order lines belonging to the selected order.

Create Table

Select only those columns that need to be in the order lines table..

Edit Table Columns

STEP 8: Adding Commit and Rollback functionality

In order to commit or rollback any changes to the database, the editOrders page needs buttons or links to invoke this functionality. This can easily be achieved by dropping both the commit and rollback operations from the datacontrol on to the editOrders page.

Add Commit and Rollback

Finally add one more button so that the editOrders page can navigate back to the browseOrders page. Optionally add command links to the BlackBerry menu for each command button so that these actions can also be invoked from the BlackBerry Menu.

The Oracle ADF Mobile Client Application is now ready for deployment.

STEP 9: Deploying the application

Before deployment, you need to set up the Mobile Client Preferences. Oracle JDeveloper needs to be able to locate the BlackBerry JDE directory, the BlackBerry Simulator directory and the Olite directory in order to do a successful deployment.

Mobile Client Preferences

On the Mobile Client project in Oracle JDeveloper select deploy…. from the mouse menu.

The first time you deploy the application you have to create a new deployment profile. In the new gallery, pick Oracle ADF Mobile Client for Blackberry.

New Deployment Profile

Give the profile a name so it can be identified at any time.

Create Deployment Profile

Accept all the default settings in the deployment profile, except for the part where you configure Application Data Publication. Here you need to configure to connection to the Oracle Mobile Server in order to create the appropriate publication items during Application Data Publication.

Here you have two options: Option one is to configure the Database Connection for the Mobile Server and the Mobile Server Login Credentials for Synchronization. Also you need to provide a valid name for the On Device Database.

Application Data Publication

The other option is to use a pre-created Mobile Client Database. You can download such a pre-created Mobile Client Database from the Oracle Technology Network Website at the Oracle ADF Mobile homepage. This database works with most mobile client applications that are based on the Fusion Order Demo.

If you go for this option, you do not need to enter the DB connection in the deployment profile. You have to set enter the full path for the Device Database Name to the location where you downloaded the pre-created Mobile Client Database.

Using a full path to a Device Database

Now you are ready to deploy the application to the BlackBerry device (or simulator) so it can be tested in the BlackBerry. On the mobileClient project in JDeveloper select deploy…. from the mouse menu. You will find several deployment actions listed. Pick Deploy to Device. If you have a simulator running, the wizard will deploy the application to the simulator, unless you have an actual device connected. The option Deploy to Package is needed when you are deploying to multiple devices using BlackBerry Enterprise Server.

deploy.png

Click Finish to deploy the mobile application to a BlackBerry deployment package.

You can also deploy the application directly to a BlackBerry device. If you have an actual device connected, the application will be deployed to the BlackBerry. However, you will need to invoke the BlackBerry signature tool first. Your application must be signed using a signature key (provided by RIM) before you can load the application .cod files onto the BlackBerry smartphone.

To request code signatures, perform the following actions:

• Request signature key from BlackBerry, at http://na.blackberry.com/eng/developers/javaappdev/codekeys.jsp
• Make sure the necessary signing files are copied to the BlackBerry Java Development Environment installation location.
• Open deployment profile, and check the “launch signature tool”, “automatically request signature”, “close tool after requesting signature”, and “close tool after requesting signatures, no error” check boxes (Figure 34).

BlackBerry options

Deploy, and fill in the necessary information. The application will get signed.

Optional steps: Configuring Data Synchronization

This step assumes you have a fully configured Oracle Lite implementation on the database server.

Your Oracle ADF Mobile Client project has been defined, but you still need to specify which data from the server gets synchronized with the client database on the mobile device. To do this, you create publication items. Each publication item defines one table on the mobile device and is mapped to a table in the server schema.

In the Deployment Profile you need to specify database connection for the mobile server repository, and a test sync user ID and password. This is shown in figure 31where you configure the application for synchronization.

To create publication items you simply need to invoke the deployment wizard from within the Mobile Client project. Once in the wizard, pick Publish Application Data.

Publish Application Data

The Deploy wizard automatically creates the publication items corresponding to the table and columns in the application and from the server schema. Once all of your publication items have been defined, they are automatically grouped together in a publication, and published to the database server. The publication defines the schema for your mobile application.

In the Deployment Log in Oracle JDeveloper you can monitor the process and see what publication items are being created. Oracle JDeveloper generates a ‘Mobile Workbench” project file (*.mpj). You will find this file in “\Model\mobile\\.mpj “. You also might want to check the publication status in the Oracle Mobile Database Workbench.

You now can deploy the application (see previously), run it on the device and try to synchronize with the database server. If you do not already have a database on the device, the first time you invoke the synchronization on the device, an on device database will be created.

Conclusion

Oracle JDeveloper and Oracle ADF enable developers to extend the reach of their enterprise applications to mobile devices. By leveraging the same set of skills, same development tool, and same development framework used for regular application development, Oracle JDeveloper and Oracle ADF dramatically lower the learning curve typically associated with mobile application development.

Additional Resources

The following resources will help to get started on BlackBerry development using Oracle ADF and Oracle JDeveloper today:

• Oracle ADF Mobile Tutorial: "Creating a Mobile Browser-friendly Oracle ADF Application"
• Sample Oracle ADF Mobile Application Project: This project is based on Oracle ADF Mobile tutorial. You can run this project once you have deployed Fusion Order Demo schema to a database, as instructed in the Oracle ADF Mobile Tutorial.
• Oracle ADF Mobile Demo Site: Navigate to this site on the BlackBerry to see the browser application in action.
• Oracle ADF Mobile Browser Developer Guide
• Oracle ADF Mobile Client Developer Guide
• Oracle JDeveloper & Oracle ADF Discussion Forum
• Apache MyFaces Trinidad Project: All of the mobile rendering support is provided by Trinidad components. For additional details and techniques around using Trinidad components, please visit the project Website.
• Running Mobile Device Simulators with Oracle ADF Mobile and JDeveloper

Android Challenges iPhone, Users Win

As I sat in the audience at Google's I|O conference Thursday morning, I watched Google VP of Engineering Vic Gundotra and others unveilAndroid 2.2 "Froyo," an ambitious upgrade to the company's mobile OS. Gundotra began the keynote by framing Android as a moral crusade against "a future where one man, one company, one device, one carrier would be our only choice."

In case anyone couldn't figure out who the man, company, device, and carrier were, he showed a slide that alluded to Apple's most famous commercial. Then, for the rest of the Android 2.2 announcement, Gundotra and others punctuated demos of impressive stuff -- such as dramatic speed boosts and Wi-Fi hotspot capabilities -- with asides about the iPhone and iPad that appeared to be intended to elicit snickers from the audience. Which they did.

Apple's WWDC conference kicks off in a little over two weeks. Like I|O, it'll be held at San Francisco's Moscone West. Apple hasn't even formally announced that the event will include a keynote, but I'm assuming there's a good chance I'll sit in the same auditorium I was in yesterday, listening to Steve Jobs talk about the next iPhone. Even if he never mentions Google by name, he'll surely aim some little jibes in the direction of Apple's competitors, if only during the inevitable prefatory bit where he updates attendees on iPhone's competitive position. Even if he doesn't, we already know that he thinks Android is out to "kill" the iPhone.

Google and Apple both seem to take the competition between Android and iPhone as an existential, company-defining battle. They're both pouring awesome resources into their work. They're building really good products which, for all their similarities, express strikingly different visions of what a mobile platform should be. And the market appears to be more than big enough for both companies to do well.

It's great -- some of the fiercest, healthiest, most consumer-benefiting rivalry I can think of in the entire history of personal technology. (That history has surprisingly few examples of sustained competition between two giants, in part because one of the giants was so often Microsoft, who -- back in the day -- played hardball more ruthlessly than anyone, and usually against companies who made some truly boneheaded strategic missteps.)

On one side, you've got Apple, which has built the world's most usable, influential mobile operating system,. It's got the biggest and best selection of applications, even though Apple's developer agreement and App Store approval process seriously constrain what developers can do. The company says thatkeeping Flash off the iPhone is a good deed, and is willing to deny users basic features such as multitasking until it nails them. And it sells only one model of phone (unless you want the 2008 version), on one not-exactly-beloved U.S. carrier.

On the other side, there's Android -- a technically solid operating system which appears to have been designed by folks with minimal interest in issues of usability. (At yesterday's keynote, I kept waiting...and waiting...for news of improvements to the Android interface.) It's got a smaller collection of apps, but one that's growing quickly in both quantity and quality, with no micromanaging restrictions on developers. Google is embracing Flash, and adding features to Android that still feel a tad futuristic. (Android's about to get a built-in voice-recognition/text-to-speech autotranslation feature; the chances that Apple is working on anything similar are pretty much zero.) And there are a bevy of Android phones -- ones with varying sizes, specs, and features, on every carrier.

I'm not saying that nobody's allowed to grumble about these two companies and platforms -- hey, I own an iPhone 3GS and a Droid and have aired my share of gripes about both of them. But with both the iPhone and Android in such robust health, everyone who buys a phone gets to decide which vision to buy into. (Or, of course, to buy a BlackBerry, a WebOS phone, a Symbian one, or something else.) And by voting with their dollars, it's consumers -- not Google or Apple -- that will determine what the future of mobile computing and communications looks like.

Here's the future I'm hoping for: one in which both companies duke it out in the marketplace (not the courtroom) for years to come. So bring it on -- snarky comments, self-serving melodrama, and all.