Welcome!

Java Authors: AppDynamics Blog, Charles Jolley, Liz McMillan, Sematext Blog , Elizabeth White

Related Topics: Java

Java: Article

The New PDA Profile

The New PDA Profile

J2ME developers have long desired the opportunity to build sophisticated applications for the personal digital assistant (PDA) market, applications common to resource-rich desktop computers. One thing stood in their way: most PDAs lacked resources to efficiently execute those applications.

However, that's about to change with the introduction of ARM processor-based PDAs and the PDA Profile that's soon to be incorporated in SDKs and VMs.

Improvements in processor design have transformed new PDAs into a powerhouse platform capable of running sophisticated J2ME applications and clients of enterprise Java systems. New PDAs bring higher performance previously known only on desktop computers.

With performance and power barriers removed from the new PDA, a committee of the Java Community Process that included PalmSource, the software division of Palm, defined a new profile called the PDA Profile (PDAP) that introduces classes for building highly responsive J2ME applications.

PDAP is an extension of the Connected, Limited Device Configuration (CLDC) 1.1 and the Mobile Information Devices Profile (MIDP) 1.0. New PDAs powered by an enhanced processor are capable of running both MIDP applications and PDAP applications using a PDAP-enabled VM. There are two key features introduced with the PDAP: the capability to develop sophisticated graphical user interfaces for a PDAP application using the Abstract Windowing Toolkit (AWT - a subset of the J2SE AWT), and the capability to access a PDA's native personal information data. A PDAP application can access data managed by the PDA device's address book, calendar, and to-do list applications.

The New PDA
I use the term "new PDA" to describe the latest incarnation of a PDA, but that doesn't help you know if a PDA can run PDAP applications. A better definition of "new PDA" is to describe the footprint required to run a PDAP application.

A PDA must have a minimum of 1,080KB of memory: 500KB for CLDC and MIDP, 540KB for the PDAP user interface libraries, 20KB reserved for the PIM API, 10KB for the Generic Connection Framework, and another 10KB for the PDAP security model. Table 1 describes other hardware configurations that are required to run a PDAP application.

PDAP and MIDlets
A PDAP application is called a PDAlet, which is a variation of the MIDlet application model. Actually, a PDAlet is a MIDlet that uses the PDAlet API and follows the same principles used in a MIDlet and MIDlet suite.

There isn't a PDAlet class because a PDAlet is a conceptual entity that refers to the capabilities and requirements of a PDAlet. A PDAlet is created by defining a class that extends the MIDlet class. Think of it as an extension of a MIDlet; those rules that apply to a MIDlet also apply to a PDAlet.

Listing 1 shows an empty MIDlet and Listing 2 converts this empty MIDlet into an empty PDAlet by calling the getDefaultToolkit() method within the startApp() method. The default toolkit is a subset of AWT and is used to create a GUI for the PDAlet. The getDefaultToolkit() method makes the PDAP API available to the PDAlet.

Although many developers will use AWT components to build a GUI for their PDAP application, a GUI isn't required for a PDAlet. You can create a PDAlet without having a GUI by calling the Display.setCurrent(null) method within the startApp() method. The PDAlet is then placed in the active-without-UI state, which means the PDAlet is still active but the implementation determines what, if anything, is displayed on the screen.

The PDAlet Suite
A PDAlet suite's functionality is similar to a MIDlet suite's in that both are packages of PDAlets and MIDlets, respectively. Suites make it easy for the developer to group related PDAlets and MIDlets for deployment and installation.

A PDAlet suite is a bundle of PDAlets and MIDlets that's implemented simultaneously on a PDA. All PDAlets (and MIDlets if any) within a PDAlets suite are considered a group and must be installed and uninstalled as a group. Each PDAlet and MIDlet within the PDAlet suite must be listed in the PDAlet suite's manifest, which is also contained in the PDAlet suite.

Members of a PDAlet suite share the same resources from the host environment and share the same Java class instances, and run within the same JVM. This means if three PDAlets from the same PDAlet suite run the same class, only one instance of the class is created. A key benefit of the relationship between PDAlet suite members is that they share the same data, including persistent storage such as that used to store user preferences.

Sharing data among PDAlets exposes each PDAlet to data errors caused by concurrent read/write access to data. However, this risk is reduced because synchronization primitives on the PDAlet suite level restrict access to both volatile and persistent data.

Data cannot be shared between PDAlets that are from another PDAlet suite because the PDAlet suite name is used to identify data associated with the PDAlet suite. A PDAlet from a different PDAlet suite is considered an unreliable source.

A PDAlet suite is installed, executed, and removed by the application manager running on the device (the manufacturer of the PDA provides the application manager).

Once a PDAlet suite is installed, the application manager gives each member of the PDAlet suite access to JVM and CLDC classes. Likewise a PDAlet can access classes defined in the MIDP and PDAP to interact with the user interface, network, and persistent storage.

The application manager also makes the Java Archive File (JAR) file and the Java application descriptor file (JAD) available to members of the PDAlet suite. Note that the JAD file is optional.

All the files that are necessary to implement a PDAlet suite must be contained within a production package called a Java Archive File (JAR). These files include PDAlet classes, graphic images if required by a PDAlet, and the manifest file.

The Manifest
A PDAlet suite is created almost the same way you create a MIDlet suite except PDAlets are identified within the PDAlet suite's manifest using the PDAlet=<name> attribute, where name represents the name of the PDAlet class.

The manifest file contains a list of attributes and related definitions that are used by the application manager to install the files contained in the JAR onto the small computing device. There are 10 attributes that are defined in the manifest file; all but seven of these attributes are optional.

Table 2 lists attributes contained in a manifest file. Of these, the following attributes are required for every manifest file. Failure to include them causes the application manager to halt the installation of the JAR file.

MIDlet-Name
MIDlet-Version
MIDlet-Vendor
MicroEdition-Profile
PDAlet-n
MIDlet-n
MicroEdition-Configuration

Listing 3 is a manifest file that contains the minimum number of attributes. All these attributes are required for a PDAlet manifest. Create a manifest file as a text file with the .txt file extension using an editor. The manifest file's file extension is changed to .mf when the PDAlet suite is prepared for deployment.

Entries in the manifest are name:value pairs and can therefore appear in any order within the manifest file. Each pair must be terminated with a carriage return. Whitespace between the colon and the attribute value is ignored when the application manager reads the manifest file.

Let's step through the manifest file shown in Listing 3. The MIDlet-Name attribute specifies the name of the PDAlet suite. The MIDlet-Version and MIDlet-Vendor attributes identify the version number of the PDAlet suite and the company or person who provided it.

The MIDlet-n attribute and the PDAlet-n attribute contain information about each MIDlet and each PDAlet that is in the JAR file. The number of the MIDlet and PDAlet replaces the letter n. The MIDlet-n attribute and the PDAlet-n attribute can contain three values that describe the MIDlet/PDAlet. A comma separates each value.

The first value is the name of the MIDlet/PDAlet. Next is an optional value that specifies the icon that will be used with the MIDlet/PDAlet. The icon must be in the Portable Network Graphics (PNG) image format. The last value for the MIDlet/PDAlet attribute is the MIDlet class name. The application manager uses the class name to load the PDAlet.

The next MIDlet/PDAlet attribute is the MicroEdition-Profile, whose value is the J2ME profile that's required to run the PDAlet. In this example the PDAP-1.0 profile is required. And the last MIDlet/PDAlet attribute is the MicroEdition-Configuration, which identifies the J2ME configuration that's necessary to run the MIDlet/PDAlet.

Attributes can be listed in any order in the PDAlet manifest and may contain spaces. The PDAlet manifest cannot have the MIDlet-Jar-URL and MIDlet-Jar-Size attributes. Both these attributes are permitted in the MIDlet manifest.

PDAlet/MIDlet Options
A PDAlet suite can contain PDAlets and MIDlets, and both are listed in the manifest as illustrated in the previous example. Both a PDAlet and a MIDlet listed in the manifest can provide the same functionality except that the PDAlet uses the PDAP API and the MIDlet uses the MIDP API.

If the implementation doesn't support the PDAP API in the VM, both PDAlets and MIDlets in the PDAlet suite won't run. However, you can specify that a MIDlet should run in place of a PDAlet by assigning the same index number to a PDAlet and a MIDlet. The PDAlet runs if the implementation supports the PDAP API, otherwise the MIDlet runs.

Listing 4 illustrates this technique. Notice there are two poker programs in this manifest. The first is MIDlet-2 and is called poker. The other is PDAlet-2 and is called PDAPoker. Since MIDlet-2 and PDAlet-2 have the same index number, the PDAPoker is the preferred poker program if the device supports the PDAP API. The MIDlet-2 program is used if the device does not support the PDAP API.

It's critical that the numbering sequence of MIDlets and PDAlets remain sequential without duplication except to resolve preferences, as in the case of PDAlet-2. Although there are six programs in the manifest in Listing 4, only five programs are visible to the implementation. Only one program is visible per index number.

Both the PDAP 1.0 and CLDC 1.1 APIs must be present on the device to install and execute the PDAlet suite, because these values are specified in the MicroEdition-Profile and MicroEdition-Configuration attributes in the manifest. The MIDP 1.0 API is implied whenever you specify the PDAP 1.0 profile in the MicroEdition-Profile attribute. However, you can explicitly specify the MIDP 1.0 API and the PDAP 1.0 profile together by including the MIDP 1.0 in the MicroEdition-Profile attribute as shown here:

MicroEdition-Profile: PDAP-1.0 MIDP-1.0

A PDAlet suite that contains both MIDlets and PDAlets requires both the PDAP API- and the MIDP API-compatible VM to install and execute the PDAlet suite. However, there are times when you want the PDAlet suite to be installed and execute only the MIDlets within the PDAlet suite if the VM is only MIDP 1.0. In this situation, you can specify that the PDAP API is optional.

To specify that the PDAP API is optional to run the PDAlet use the MicroEdition-Profile-Opt manifest attribute as shown in the following code segment. The PDAlet suite will install and execute on a MIDP 1.0-only VM. Only MIDlet programs will be installed and executed. PDAlets are considered application-specific attributes and are not available for execution.

MicroEdition-Profile: MIDP-1.0
MicroEdition-Profile-Opt: PDAP-1.0
MicroEdition-Configuration: CLDC-1.1

Java Application Descriptor File
Application management software uses a Java Application Descriptor File (JAD) to manage the PDAlet, and the JAD can be used by the PDAlet to configure specific attributes. You may include a JAD within the JAR file of a PDAlet suite as a way to pass parameters to a PDAlet without modifying the JAR file. A JAD file is also used to provide the application manager with additional content information about the JAR file to determine if the PDAlet suite can be implemented on the device.

A JAD file is similar to a manifest in that both contain attributes that are name:value pairs. Name:value pairs can appear in any order within the JAD file. There are six required system attributes for a JAD file, see below. A system attribute is an attribute that's defined in the J2ME specification. Table 3 contains a complete list of system attributes. All JAD files must have the .jad extension. Listing 5 illustrates a typical JAD file.

MIDlet-Name
MIDlet-Version
MIDlet-Vendor
PIDlet-n
MIDlet-n
MIDlet-Jar-URL

The JAD file shown in Listing 5 contains a few attributes that are also found in the manifest file. The first three attributes in the JAD are identical to attributes in the manifest file.

The MIDlet-Jar-URL attribute contains the URL of the JAR file, which in this example is called bestmidlet.jar. The last required attribute in the JAD file is the MIDlet-n and PDAlet-n attribute that defines a PDAlet and MIDlet of the PDAlet suite that's identical to the PDAlet-n and MIDlet-n attributes of the manifest. A MIDlet-n attribute is required for each MIDlet in the PDAlet suite, and a PDAlet-n attribute is required for each PDAlet in the PDAlet suite.

A word of caution: the values of the MIDlet-Name, MIDlet-Version, and MIDlet-Vendor attributes in the JAD file must match the same attributes in the manifest. If the values are different, the application manager uses the attribute of the JAD file. Failure to include these attributes in the JAD file will prevent the JAR file from loading into the device.

A developer can include application attributes in a JAD file. An application attribute is a name:value pair that contains a value unique to the application. Any name can be given to an application attribute as long as the name does not begin with MIDlet-, PDAlet-, or MicroEdition-.

Abstract Windowing Toolkit
The PDA profile uses common user interface elements of the Java Abstract Windowing Toolkit (AWT) as the user interface solution for PDAlets. These user interface elements are native to many PDAs that use the ARM processor.

The AWT used in the PDA profile is a subset of the J2SE AWT that's designed to utilize the limited display space and memory constraints found in a PDA. This subset contains all the features that you'll require when developing a PDA application.

A subset of AWT is used as the user interface API for two J2ME profiles: Personal Basis Profile (PBP) and Personal Profile (PP). Each is used for a targeted class of devices. As a point of reference, the PDAP AWT is a subset of the Personal Profile.

The PDA Profile subset contains support for all but the following features:

  • Serialization of UI components
  • Object cloning
  • J2SE security model
  • Buffered images
  • Data transfer APIs
  • Alpha composite image manipulation
Characteristics of PDA Profile AWT
PDAlets run on a variety of PDA devices, each having support for some set of graphical user interface elements. Fortunately for developers, PDA devices that run PDAP API-capable VMs must adhere to a minimum of GUI elements that enable you to design a PDAlet that can take advantage of these GUI elements.

Color choices for your PDAlet GUI might be limited to black and white since these are the only two colors that an implementation is required to support. Realistically, however, many implementations will support a variety of colors through the RGB constructor for the Color class. Therefore it's wise to test your PDAlet on as many implementations as possible to be assured that your color choices don't negatively impact your application.

You also need to be alerted to the fact that some implementations that support a broad color palette may not permit you to change the colors of standard GUI elements such as menus and title bars. However, this lack of support doesn't prevent you from calling methods to change the color of those elements. The implementation won't throw an error, but will simply ignore your request to change the color of the element.

In some PDAlets you may want to set your own cursor using the AWT Component class. While setting the cursor is commonplace in J2SE applications, you might not be able to do so using the PDAP API because some implementations may prohibit such settings. Attempts to set the cursor will cause a silent error. The implementation will continue to run your PDAlet, but ignore your request to change the cursor.

Avoid using a variety of fonts in your application's graphical user interface because they may not be supported by the implementation. The PDAP only requires support for Font.Plain. Support for other fonts is implementation dependent. You can't assume that a font other than Font.Plain is available unless your application is tailored to run on a specific implementation.

Another limitation of running a PDAlet is thread safety. The PDAP does not mandate that AWT be thread safe. Therefore, avoid concurrent access to GUI objects using different threads. However, you can use a system event thread to enable concurrent access by calling the static invokeLater() method and the invokeAndWait() methods of the EventQueue class.

AWT offers window management capabilities that enable you to instantiate frames, windows, and dialogs from anywhere in the PDAlet and then show them by calling appropriate methods. All PDAP implementations support multiple top-level windows that are visible at any given time.

However, there are window management limitations that restrict windowing. Only one top-level window (window, frame, or dialog classes) can be shown (seen by the user) and active (has input focus) at a time. Some implementations might permit multiple top-level windows to be shown and be active simultaneously.

Tip: The implementation determines the behavior of windowing for the application if your PDAlet does not make a top-level window visible.

Top-level windows may not be resizable by your PDAlet or by the user, and calls to the setSize() method are silently ignored. Therefore, you should assume that resizing is not available unless you're designing an application for a specific PDA that you know enables top-level windows to be resized.

Likewise, you should expect that the implementation might limit or prohibit the resizing of dialogs. Attempts to change the size of a dialog may result in a different size than the size you requested - or no change whatsoever. Implementations that prohibit resizing of dialogs will not notify your application that an attempt to resize has failed. Instead, they ignore your request to resize the dialog.

Always minimize the need to change the size of a dialog within your application. If you must change the dialog size, make sure you test those changes on all the implementations that will be running your application in order to determine the visual effect those changes have on the application's graphical user interface. Failure to do so might result in an unexpected GUI for your PDAlet.

Additional restrictions might apply to the location of dialogs on the screen. Some implementations may limit the location on the screen where you can display the dialog, and other implementations outrightly prohibit the application to determine where the dialog is displayed on the screen. And, as with other prohibitions discussed in this section, your PDAlet continues to run uninterrupted because your request for change is ignored by the implementation.

PDAP does not require that an implementation provide a means to display a title for a dialog. This means that calling the setTitle() method and getTitle() method have no effect on the dialog.

Frames also have many of the restrictions found in dialogs. You can expect that an implementation will support a one-sized frame that can't be resized by a user or an application. An attempt to size or resize a frame causes a silent error to occur without an error message being sent to your application.

Likewise, the location of a frame is determined by the implementation, not by the application or the user of the application. Frames also can't be iconified or titled. As with all the restrictions discussed in this section, an implementation may not have these restrictions.

Personal Information Management
A PDA device has native personal information management (PIM) data that's managed by personal information applications that run on the PDA device. The PDA profile requires that an implementation grant PDAlets access to PIM data. This means that your PDAlet can access data managed by the PDA device's address book, calendar, and to-do list applications. PIM data does not have to reside on the device. Your PDAlet can access the data even if the information is contained on a remote device, such as a PC that's linked to the PDA device.

The PDAP API implementation will handle security management to prevent unauthorized Java applications from accessing PIM databases. The implementation also provides a mechanism to enable a PDAlet to access PIM data efficiently without hindering performance.

PIM data can be imported and exported using a format specified by the Internet Mail Consortium. The vCard 3.0 format is used for address book entries and the vCalendar 1.0 format is used for calendar and to-do entries.

You can access PIM data directly from your PDAlet by using the PDAP PIM API found in the javax.microedition.pim package. All PDAP implementations support the PDAP PIM API.

There are three types of PIM databases supported by the PDAP PIM API: Event, Contact, and ToDo. The Contact Database also supports a photo field that can receive and store data in any of the IANA registered image formats or a nonstandard image format. The Photo field is consistent with the definition of the PHOTO field in the vCard specification and must support the Portable Network Graphics (PNG) format.

Connectivity
Every PDAP implementation must have an HTTP connection for networking devices, which is the same requirement for the MIDP profile. However, some implementations may support the Generic Connection Framework API, the logical serial port connection using CommConnection class, as well as the file systems and/or removable memory cards using the FileConnection class.

Support for the logical serial port connection and for the file systems is dependent on the operating system and hardware support that's available on the device running the PDAP implementation. The device is not necessarily required to have a serial port connection if the device's operating system enables an IR port to be configured as a logical serial port.

The file system of a device that implements PDAP is typically located either in the device's memory or on memory cards, depending on the device and the limits of the operating system. Memory cards that contain file systems include:

  • SmartMedia Card (SSFDC)
  • CompactFlash Card (CF)
  • Secure Digital Card (SD)
  • MultiMedia Card (MMC)
  • MemoryStick (MS)
Security
There are multiple security features imposed by the PDA profile that protect the user of the application and the device from malicious access and use. The PDA employs the sandbox security model that's implemented in CLDC 1.1 and MIDP 1.0. Security is further enhanced by the authorization security that enforces access privileges on resources of the device. These enhanced security policies will also be found in MIDP 2.0.

The enhanced security policies are hidden from the application and become visible only if a security exception occurs when using the PDAP API privilege functionality. Restrictions and permissible actions are associated with all PDAlets and MIDlets in a PDAlet suite and all code that runs on behalf of a member of the PDAlet suite.

The implementation determines how authorization results and configuration settings are presented to the user in the user interface. However, the implementation will require privileges to:

  • Read data from and write data to a PIM database
  • Read data from and write data to components (i.e., files, directories) of the file system
  • Read data from and write data to input/output streams
  • Access the AWT system event queue
  • Listen to all AWT events

    A Welcome Addition
    J2ME developers who design and build applications for PDAs will find the PDA Profile an invaluable addition to their development arsenal, enabling the creation of powerful applications that take advantage of a new PDA footprint. The PDA Profile provides specifications for a rich set of AWT components that are used to implement sophisticated graphical user interfaces for PDA applications, GUIs similar to those found on desktop applications.

    The PDA Profile also gives J2ME applications access to information stored on a PDA by proprietary, personal information management software that OEMs supply with the devices. This means your J2ME application can interact with a PDA's address book, calendar, and to-do list, including storing your own information in the databases used by these applications. Combining connectivity and security capabilities with AWT and personal information management, the PDA Profile is the right tool for every J2ME developer.

  • Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    @ThingsExpo Stories
    The Internet of Things is not new. Historically, smart businesses have used its basic concept of leveraging data to drive better decision making and have capitalized on those insights to realize additional revenue opportunities. So, what has changed to make the Internet of Things one of the hottest topics in tech? In his session at @ThingsExpo, Chris Gray, Director, Embedded and Internet of Things, discussed the underlying factors that are driving the economics of intelligent systems. Discover how hardware commoditization, the ubiquitous nature of connectivity, and the emergence of Big Data a...
    "BSQUARE is in the business of selling software solutions for smart connected devices. It's obvious that IoT has moved from being a technology to being a fundamental part of business, and in the last 18 months people have said let's figure out how to do it and let's put some focus on it, " explained Dave Wagstaff, VP & Chief Architect, at BSQUARE Corporation, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4-6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
    The major cloud platforms defy a simple, side-by-side analysis. Each of the major IaaS public-cloud platforms offers their own unique strengths and functionality. Options for on-site private cloud are diverse as well, and must be designed and deployed while taking existing legacy architecture and infrastructure into account. Then the reality is that most enterprises are embarking on a hybrid cloud strategy and programs. In this Power Panel at 15th Cloud Expo (http://www.CloudComputingExpo.com), moderated by Ashar Baig, Research Director, Cloud, at Gigaom Research, Nate Gordon, Director of T...
    SYS-CON Events announced today that IDenticard will exhibit at SYS-CON's 16th International Cloud Expo®, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY. IDenticard™ is the security division of Brady Corp (NYSE: BRC), a $1.5 billion manufacturer of identification products. We have small-company values with the strength and stability of a major corporation. IDenticard offers local sales, support and service to our customers across the United States and Canada. Our partner network encompasses some 300 of the world's leading systems integrators and security s...
    SYS-CON Events announced today that Windstream, a leading provider of advanced network and cloud communications, has been named “Silver Sponsor” of SYS-CON's 16th International Cloud Expo®, which will take place on June 9–11, 2015, at the Javits Center in New York, NY. Windstream (Nasdaq: WIN), a FORTUNE 500 and S&P 500 company, is a leading provider of advanced network communications, including cloud computing and managed services, to businesses nationwide. The company also offers broadband, phone and digital TV services to consumers primarily in rural areas.

    ARMONK, N.Y., Nov. 20, 2014 /PRNewswire/ --  IBM (NYSE: IBM) today announced that it is bringing a greater level of control, security and flexibility to cloud-based application development and delivery with a single-tenant version of Bluemix, IBM's platform-as-a-service. The new platform enables developers to build ap...

    The BPM world is going through some evolution or changes where traditional business process management solutions really have nowhere to go in terms of development of the road map. In this demo at 15th Cloud Expo, Kyle Hansen, Director of Professional Services at AgilePoint, shows AgilePoint’s unique approach to dealing with this market circumstance by developing a rapid application composition or development framework.
    “In the past year we've seen a lot of stabilization of WebRTC. You can now use it in production with a far greater degree of certainty. A lot of the real developments in the past year have been in things like the data channel, which will enable a whole new type of application," explained Peter Dunkley, Technical Director at Acision, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
    DevOps Summit 2015 New York, co-located with the 16th International Cloud Expo - to be held June 9-11, 2015, at the Javits Center in New York City, NY - announces that it is now accepting Keynote Proposals. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential.
    "People are a lot more knowledgeable about APIs now. There are two types of people who work with APIs - IT people who want to use APIs for something internal and the product managers who want to do something outside APIs for people to connect to them," explained Roberto Medrano, Executive Vice President at SOA Software, in this SYS-CON.tv interview at Cloud Expo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
    Nigeria has the largest economy in Africa, at more than US$500 billion, and ranks 23rd in the world. A recent re-evaluation of Nigeria's true economic size doubled the previous estimate, and brought it well ahead of South Africa, which is a member (unlike Nigeria) of the G20 club for political as well as economic reasons. Nigeria's economy can be said to be quite diverse from one point of view, but heavily dependent on oil and gas at the same time. Oil and natural gas account for about 15% of Nigera's overall economy, but traditionally represent more than 90% of the country's exports and as...
    The Internet of Things is a misnomer. That implies that everything is on the Internet, and that simply should not be - especially for things that are blurring the line between medical devices that stimulate like a pacemaker and quantified self-sensors like a pedometer or pulse tracker. The mesh of things that we manage must be segmented into zones of trust for sensing data, transmitting data, receiving command and control administrative changes, and peer-to-peer mesh messaging. In his session at @ThingsExpo, Ryan Bagnulo, Solution Architect / Software Engineer at SOA Software, focused on desi...
    "At our booth we are showing how to provide trust in the Internet of Things. Trust is where everything starts to become secure and trustworthy. Now with the scaling of the Internet of Things it becomes an interesting question – I've heard numbers from 200 billion devices next year up to a trillion in the next 10 to 15 years," explained Johannes Lintzen, Vice President of Sales at Utimaco, in this SYS-CON.tv interview at @ThingsExpo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
    "For over 25 years we have been working with a lot of enterprise customers and we have seen how companies create applications. And now that we have moved to cloud computing, mobile, social and the Internet of Things, we see that the market needs a new way of creating applications," stated Jesse Shiah, CEO, President and Co-Founder of AgilePoint Inc., in this SYS-CON.tv interview at 15th Cloud Expo, held Nov 4–6, 2014, at the Santa Clara Convention Center in Santa Clara, CA.
    SYS-CON Events announced today that Gridstore™, the leader in hyper-converged infrastructure purpose-built to optimize Microsoft workloads, will exhibit at SYS-CON's 16th International Cloud Expo®, which will take place on June 9-11, 2015, at the Javits Center in New York City, NY. Gridstore™ is the leader in hyper-converged infrastructure purpose-built for Microsoft workloads and designed to accelerate applications in virtualized environments. Gridstore’s hyper-converged infrastructure is the industry’s first all flash version of HyperConverged Appliances that include both compute and storag...
    Today’s enterprise is being driven by disruptive competitive and human capital requirements to provide enterprise application access through not only desktops, but also mobile devices. To retrofit existing programs across all these devices using traditional programming methods is very costly and time consuming – often prohibitively so. In his session at @ThingsExpo, Jesse Shiah, CEO, President, and Co-Founder of AgilePoint Inc., discussed how you can create applications that run on all mobile devices as well as laptops and desktops using a visual drag-and-drop application – and eForms-buildi...
    We certainly live in interesting technological times. And no more interesting than the current competing IoT standards for connectivity. Various standards bodies, approaches, and ecosystems are vying for mindshare and positioning for a competitive edge. It is clear that when the dust settles, we will have new protocols, evolved protocols, that will change the way we interact with devices and infrastructure. We will also have evolved web protocols, like HTTP/2, that will be changing the very core of our infrastructures. At the same time, we have old approaches made new again like micro-services...
    Code Halos - aka "digital fingerprints" - are the key organizing principle to understand a) how dumb things become smart and b) how to monetize this dynamic. In his session at @ThingsExpo, Robert Brown, AVP, Center for the Future of Work at Cognizant Technology Solutions, outlined research, analysis and recommendations from his recently published book on this phenomena on the way leading edge organizations like GE and Disney are unlocking the Internet of Things opportunity and what steps your organization should be taking to position itself for the next platform of digital competition.
    The 3rd International Internet of @ThingsExpo, co-located with the 16th International Cloud Expo - to be held June 9-11, 2015, at the Javits Center in New York City, NY - announces that its Call for Papers is now open. The Internet of Things (IoT) is the biggest idea since the creation of the Worldwide Web more than 20 years ago.
    As the Internet of Things unfolds, mobile and wearable devices are blurring the line between physical and digital, integrating ever more closely with our interests, our routines, our daily lives. Contextual computing and smart, sensor-equipped spaces bring the potential to walk through a world that recognizes us and responds accordingly. We become continuous transmitters and receivers of data. In his session at @ThingsExpo, Andrew Bolwell, Director of Innovation for HP's Printing and Personal Systems Group, discussed how key attributes of mobile technology – touch input, sensors, social, and ...