
Newton Technology Journal June 1996
13
The NewtApp framework is a collection of system-supplied protos which
can be combined to form a complete application. In the past, creating an
application for Newton PDAs usually required assembling many protos to
form a complete application. What sets NewtApp apart is the amount of
functionality built into the NewtApp framework. Support for the basic
system services – filing, finding, routing, overview management, stationery,
and so on, is provided in the NewtApp protos. The process of creating an
application with NewtApp consists primarily of describing your application’s
data and how to view it. It is then a rather simple task of assembling a shell
of an application around your data. You can use DTS sample code as the
basis for that shell, or you can create your own shell. Either way, once
you’ve created your first NewtApp, it is easy to reuse that NewtApp to
contain other types of data for other applications. A future DTS sample may
contain a pre-built, reusable application shell to further accelerate
development of your own applications.
Not all types of application lend themselves to the NewtApp treatment. A
successful NewtApp is typically an application which deals with a single soup
entry at a time and whose entries all come from the same soup. When used
with the stationery mechanism, you can provide many different views of an
entry. In addition to providing multiple views of a single type of data,
stationery can be used to extend your application to use different types of
data. For example, the single application Notes can handle lined notes,
checklists and outlines. The same soup can contain items created by
different stationery, and a NewtApp can display them all.
An application can be built with NewtApp whether it uses stationery or
not. Since routing in Newton 2.0 OS is handled through stationery, and it is
often very desirable to have multiple views of individual data items,
stationery can be very useful. However, the choice is yours. If you do not
need to print or fax items, provide multiple views, or extend your
application, you can still use NewtApp. The DTS “Checkbook” sample
demonstrates the use of the NewtApp framework without stationery. In
addition, stationery can be used in an application which does not use
NewtApp. This article, however, only covers the use of NewtApp. It can
serve as a guide to both stationery- and non-stationery-based NewtApps.
The current NewtApp design has two chief limitations. First, a NewtApp
can only be used with soup-based data. Secondly, a NewtApp can only work
with entries from a single soup at a time. Therefore, it would not be
appropriate for an application like a calculator or general utility. In addition,
an application which must deal with data from several soups simultaneously,
like the built-in Calendar, would be a bad candidate for NewtApp. However,
if your application is like most Newton applications, or if you want to quickly
prototype an idea for an application, then NewtApp is a good way to go.
WHY NEWTAPP?
When NewtApp was designed it was intended as a way for the Newton
Systems Group to create the applications in the ROM as well as being a
supported framework for third-party applications. The Names, Notes, Calls
and In&Out Box applications were all built using NewtApp. As the built-in
applications for Newton 2.0 evolved, the NewtApp framework evolved along
with it. Once the framework could be used, a codification of the procedures
needed to implement an application was documented. These procedures
for using the application framework are detailed and documented
completely in the Newton Programmer’s Guide and are demonstrated in
the DTS sample code.
It is important to note that although you may be able to get different
combinations of the NewtApp protos to function as an application, alternate
construction techniques and arrangements are not supported, and may
break in the future as the NewtApp framework evolves.
There were many design goals for NewtApp. Among these were:
• Increase speed and ease of deploying common Newton applications.
• Eliminate common code in Newton applications.
• Provide system services for “free.”
• Encourage visual commonality amongst Newton applications.
• Provide an easy container for stationery.
• Allow third party applications to “Upgrade” along with the system.
Aside from the soup-based limitations, the NewtApp framework meets
these goals and is a good way to start if you’re new to Newton programming.
It is also straightforward to convert your 1.x application to 2.0 using
NewtApp. I mention the steps needed for this at the end of this article.
USING NEWTAPP
Using NewtApp to create an application may be a little different than what
you’re used to. The framework has several layers, and it may be confusing at
first to decide what should go at each layer. This section first discusses the
general technique of creating a NewtApp application, and then discusses
each of the layers. Since stationery can figure heavily in the use of NewtApp
and is a powerful mechanism for extending an application, this discussion
will also cover stationery-specific features. Chapter 5 of the Newton
Programmer’s Guide covers the use of stationery in NewtApp in detail. For
a demonstration of a complete, stationery-based NewtApp, see the DTS
Sample code called “Who-Owes-Whom.”
BEFORE YOU START
Three main flavors of Newton applications are supported by NewtApp.
These three are card, page and roll. A card application, like Names, shows
one entry at a time, and all entries are the same height as each other. A page
application is one where only one entry is shown at a time, but the entries
are of arbitrary height. The Calls application is an example of this flavor of
application. The roll flavor is one which, like the Notes application, can
show an arbitrary number of entries of arbitrary height. By supporting all
three flavors, NewtApp gives you the flexibility to experiment with different
Using the NewtApp Framework
by Greg Christie, Apple Computer, Inc.
NewtonScript Techniques
Comentários a estes Manuais