SWENG500 - Group Report

tamerunSoftware and s/w Development

Aug 15, 2012 (4 years and 8 months ago)

482 views










Team #2

Group Report










Prepared By:

Eric Borisow, Geoff Scholl, Ty Hyunh
SWENG500
-

Group Report

Project Assessment

Error! No text of specified style in document.




March 15, 2013

/
Page
2

of
11

© 200
9,

Confidential & Proprietary



1.

Project Assessment

Working with the Carpool application was a fun project. Nobody in the group had ever written
code for a mobile device before so getting started was
a learning experience and took quite a bit
of time. In addition, there were quite a few APIs that we were able to use that are truly used for
enterprise
-
level applications. Here is a listing of all of the tools and APIs that we had to work with
and/or le
arn while working with this project:




Blackberry API



Blackberry Java Development
Environment (JDE)



Hibernate Persistence



Apache Tomcat



Subversion (SVN)



Another Neat Tool (ANT)


䉵il搠獣物灴⁴dol



Eclipse



Blackberry Plugin for Eclipse



Structure 101



Spring F
ramework



Apache Axis 2



MySQL



MGMaps map API



Apache HTTP


Thankfully, Geoff already pays for a provider for the Tomcat, MySQL

and Apache HTTP server that
we could share. However, we still needed to setup our own environments to build the project
locally o
n our own desktops.

Getting Started

When we first started the project, Ty came up with the idea for the project and Eric suggested
using the Blackberry since he had one that we could use for actual testing. So, we started by
putting together a project pla
n and just laying out the basic plan for our development effort.
Since we were using a completely fixed deadline, it was easy to map out a rough estimate. We
decided that we would break up the effort into initial discovery for the project, then three
ite
rations when we would development the major components of the application. Anything that
we were planning to do had to be placed into one of the three iterations.

We knew that one of the biggest tasks for the project was going to be finding and learning a

mapping API that would satisfy our requirements. Our main task going into the first week then was
to try to figure out
which mapping API we could use. We first checked into one of the most
popular mapping APIs available which

most people would say is Go
ogle Maps
.
Although Google
Maps is a great API and is highly customizable, there was one problem. It didn’t translate well to a
mobile application. There is, of course, the Google Maps application that is available software for
the Blackberry device, bu
t unfortunately that API is closed and not available for public use for
mobile devices. The only other option is to produce a static map on a web server and point the
mobile device to the map, but that simply produces an image that is available to the use
r. No
interactivity is possible with this setup.

SWENG500
-

Group Report

Proje
ct Assessment

Error! No text of specified style in document.




March 15, 2013

/
Page
3

of
11

© 200
9,

Confidential & Proprietary



Deciding on the Map API

Our next step was to rely on finding an API by searching on the Google Search Engine. The first API
we found was called J2MEMap. The name is taken from the Java standard J2ME that
is the Java
environment that is standard on Java
-
enabled mobile phones. The Blackberry is a J2ME
-
compliant
device so using J2MEMap was a possibility. So, the first week was spent setting up a project and
trying to learn the API to see what it could do.
It was rough getting started with the API and we
found that we couldn’t get it up and running as quickly as we hoped. So, at the same time, we
started looking for any other alternatives. We found others but the most likely choice was a
product called MGM
aps. Then, for the next two weeks, we continued to vacillate between
J2MEMap and MGMaps. MGMaps gave us a compelling choice because they also had a second
version available that was written to work specifically with the Blackberry API. So, the choice wa
s
actually between three different possibilities. We could use J2ME with the J2MEMap API. We
could use J2ME with the MGMaps API. Or, we could use the Blackberry API with the MGMaps API. If
we chose one of the J2ME versions, we felt that it was more of
a conservative choice because then
we could simply swap out the map API if we ran into some issues with any particular API.

Alternatively, with the Blackberry API, we knew we would get better support on the Blackberry
device since the API was written spec
ifically for the device.

Both APIs were open
-
source and basically maintained by volunteers, so it was quite difficult to get
any level of support with the application. After a few weeks though, we decided that we want
ed

to go ahead with the MGMaps version

running on the Blackberry API. The reason was that we were
able to put together some prototypes using the MGMaps API that did most of the things that we
were trying to accomplish with our project.

Setting up the Environment

At the same time that we were
trying to decide on which map API we should use, we were also
working to build our development environment. This was happening simultaneously with our map
API prototypes since we needed to use a proper IDE to develop for the device. Even here we had a
fe
w decisions to make and it would take some time to pick the right choice. We started out
thinking that there were two primary IDEs available. One IDE from Sun is called Netbeans and is a
comprehensive IDE not unlike Eclipse, for several different Java
-
ba
sed technologies. However,
Netbeans only has a plugin for creating J2ME applications and is not designed for the Blackberry
IDE. For the Blackberry API, we found that Research In Motion (RIM), the maker of Blackberry,
created an IDE called the Blackberry

Java Development Environment (JDE). So, we installed both
to start building our prototypes. While our tight timeline wasn’t terribly conducive to learning a
new IDE, we felt that it would be important to use an IDE that was designed for the type of
deve
lopment that we would be doing. As it turned out, the Blackberry JDE was pretty clunky and,
while functional,
had the misfortune of being written as a Java Swing application which is not
really streamlined like a typical Windows application. Luckily, we
found that Blackberry had
recently released a 1.0 version of a plugin for Eclipse. So, we decided to switch over to the Eclipse

plugin since the team had more experience with that particular IDE.

Our problems with

the

Blackberry plugin for Eclipse started

pretty much from day one. After
installing the plugin, the first thing we ran into was that the plugin needed to work using a
Blackberry workspace. We spent a few nights just trying to figure out how to create a workspace
for the plugin. In fact, we wo
uld be hard
-
pressed to provide any instruction on how to actually
configure the workspace to work with the Blackberry plugin. Once we were able to get the plugin
working, the next thing we needed to figure out was how to build the Blackberry application u
sing
the Eclipse program. We can spare all of the details, but the Blackberry forums are a godsend.
However, as we went on through the project, we were constantly having to deal with disappearing
SWENG500
-

Group Report

Project Assessment

Error! No text of specified style in document.




March 15, 2013

/
Page
4

of
11

© 200
9,

Confidential & Proprietary



projects, missing links to the MGMaps librar
ies and
code

n
ot compiling.
It was frustrating to say the
least.

So, finally, we settled on the least common denominator which is ANT. ANT is a build tool that is
used regularly in Java development. It is a scripting language that allows you to automate various
tasks
from copy files, to compiling code, to creating
application packaging and performing code
signing. Thankfully, someone created a tool for ANT that allows a developer to compile and build
an application in the format required for the Blackberry. Since thi
s utility ran from the command
line, we knew that our code was getting compiled and deployed properly. So, in the end, we
settled for using Eclipse as a really nice and fancy text editor and ANT to do our compiling and
building to create files for the Bla
ckberry.

Model (Database) Code

In the meantime, while we were overcoming the challenges with the development environment
and the learning the map API, we were simultaneously building out our backend code. We knew
that we would need the ability to store ou
r data, so we built our data model and created our
database scripts. We decided to use Hibernate to perform Object
-
to
-
Relational Mapping (ORM)
between the database and the objects in our application. At the same time, a nice complement to
Hibernate is th
e Spring Framework which manages the creation and lifecycle of the components in
the application. We figured that in either case, we would need the

database services in some
form regardless of whether we had a web
-
based application or a Blackberry applica
tion.

We turned back to the Blackberry device to understand how the Blackberry accesses data. At first,
we thought that there would be a simple JDBC driver available that would simply be able to send
messages over the air. We found one API that claimed t
hat it
performs

a database operation, but
the API was written over four years ago so we weren’t
very

confident in being able to use
it
.
Surprisingly, there was not an alternative

already available

from Blackberry. The only method for
accessing any data f
rom the Blackberry was to use web services. We found a popular API called
ksoap2 that seemed pretty popular but then we discovered that there was actually a standard
available called JSR
-
172



J2ME Web Services Specification
.

So, we began implementing al
l of our
data access points as web services. To do that, we used the
Apache
Axis2 web services API on the
server side to publish our web services.

On the Blackberry (client) side, we found that we
could
generate the client web service code using the Netb
eans IDE.

Web Services Issues

The creation of the web services seemed to be pretty straight
-
forward. We didn’t really have to
deal with multiple types of clients accessing our services, so that wasn’t really a concern. The
Blackberry though, seemed to ha
ve a few issues that we needed to overcome to have our services
work correctly.

The first issue that was puzzling was the inability to use a nested element to hold a list of
elements.
To illustrate, Figure
1

shows a definition for a complex type named Tri
p and then we
defined a

WebService_Response


element for our web service that contains an element named

trips


which contains a list of trips.

SWENG500
-

Group Report

Project Assessment

Error! No text of specified style in document.




March 15, 2013

/
Page
5

of
11

© 200
9,

Confidential & Proprietary




Figure
1

-

Complex Type example

So, an example of the XML that gets passed would loo
k like Figure
2
. There is a single <trips>
element that can contain multiple <trip> elements.


Figure
2

-

XML example

Unfortunately, this doesn’t work with the Web Services that the Blackberry is expecting. The
Blackberry code i
s expecting a flattened structure so that there is no arbitrary nesting. Basically,
we needed to remove the trips element and simply output a series of <trip> elements from the
service
.

Our other web service issue had to do with nillable elements. Typica
lly, if you have an element
that is defined as nillable, you don’t need to pass any element at all. We found that the
Blackberry API has a bug where you must output an element regardless of whether or not nillable is
allowed. So, instead of passing nothi
ng, you have to pass an empty element
.

Figure
3

illustrates
the bug we found.

SWENG500
-

Group Report

Project Assessment

Error! No text of specified style in document.




March 15, 2013

/
Page
6

of
11

© 200
9,

Confidential & Proprietary




Figure
3

-

Empty element example

Mapping API Challenges


The Development Process

Early in the project, we realized that we would need to be able to sh
are source code,
documentation, etc. between the team. So, one of the tasks that we handled early in the project
was to establish an SVN repository. We found a free service that was available on the Internet
where we could create our repository for our p
roject. It is currently available at:
http://code.assembla.com/psu
-
edu
-
sweng500/subversion/nodes

Having our project in SVN made it easy for the team to work in a distributed manne
r. Source code
changes were made on the local machine and then checked in when they were ready to be shared
with the team.

Another tool

that proved helpful while working on the project
was

Microsoft
LiveMeeting

which is
software that allows you to share y
our computer desktop with other people that are invited. That
combined with a conference phone line allowed us to take a look at what
others

on the team were
doing and also
work through
troubleshooting any problems

over the phone
.

To develop the actual so
ftware, we used an iterative method where features were decided and
built individually rather than a comprehensive approach. This allowed us to remain open to new
functionality and also abandon a particular feature if we felt that we wouldn’t have enough
time.
The typical pattern that we followed was to first start by updating the database model to contain
the data that we would need.

To access the data, we would update one of the class interfaces and

write the code to access the data using Hibernate.
N
ext, we would create at least one test
method that would perform the function (such as retrieving or saving the data) that we wanted to
achieve.

With our data
-
access code in place, we would then update the WSDL for our web service
and re
-
generate the clas
ses using Axis2. Next, we would implement the interface for the web
service by invoking our data
-
access code. Once we had the web service created, it was a matter
of updating the client web service code for the Blackberry and then building the interface
to
SWENG500
-

Group Report

Project Assessment

Error! No text of specified style in document.




March 15, 2013

/
Page
7

of
11

© 200
9,

Confidential & Proprietary



invoke the web service from the Blackberry User Interface (UI).

We would continue to make
iterations until the functionality was complete.


SWENG500
-

Group Report

Lessons Learned

Error! No text of specified style in document.




March 15, 2013

/
Page
8

of
11

© 200
9,

Confidential & Proprietary



2.

Lessons Learned

Although we got there in a
roundabout way, I think we actually achieved a certain level of
matur
ity in our process and in the application. At this point, I think we would definitely be in a
good position to continue addi
ng new features to our software without major roadblocks. Most of
the major issues occurred early and in our estimate probably too
k about 4
-
5 weeks to get through.


But, once we had our environments up and we discovered the quirks in the Blackberry IDE process,
it started to go a little more smoothly.

To be fair, the mapping of objects to the database code was also a challenge. The
object property
to database column mapping was easy, but the challenge occurred when

joins needed to be made
between the tables. First, you needed to correctly map the tables in the Hibernate configuration
file, and then you needed to make sure that the H
ibernate Java code reflected the appropriate
joins at the right time. The

Blackberry bug that we discovered where all elements in a web service

message had to have an empty element certainly created extra work for us here because typically,
we would not h
ave had to retrieve all of the data that we ended up pulling. Subsequently, this
made the amount of data a little heavier because the web service had to send this extra data over
the air.

When creating web services, it is very important to get the definit
ions correct as soon as possible.

The primary reason is because if you don’t, then you end up spending a lot of time rebuilding the
web service classes on the receiver side and then you have to ask everyone to regenerate the
client stubs from the Blackber
ry application.

So, as seemingly small change can easily take one
hour to ripple through all of the layers.

For our build process, it would have been better if we had started using the ANT scripts early on in
the process to avoid a lot of frustration with

the build process. There is nothing more aggravating
than making a change to your code, running the compiler and waiting for two minutes while the
Blackberry simulator resets. Then, you discover that your change is not in the binary code from
the build
process.

Several people on the Blackberry forums suggested using the ANT tool right
from the beginning but we thought the Eclipse plugin would be better.

Unfortunately, we were
wrong in that regard.

SWENG500
-

Group Report

Best Practices

Error! No text of specified style in document.




March 15, 2013

/
Page
9

of
11

© 200
9,

Confidential & Proprietary



3.

Best Practices

There were quite a few Best Practices th
at we can pass along to others who are attempting to
create a project with similar features.

Blackberry Development

There are quite a few ways to build an application for a mobile device. There is a Java standard
API called Java 2 Micro Edition (J2ME). I
f you are developing an application that needs to run on
any type of mobile device, then you would need to use J2ME. The best IDE that we’ve found from
working with J2ME is the Netbeans IDE that is available from Sun. It contains several wizards and
visu
al editors for creating your application.

If you are not interested in creating an application that runs on any device and are more focused
on writing the application specifically for a Blackberry device, then you can also use J2ME, but the
better option w
ould be to use the Blackberry Java Development Environment
API. There were two
basic options that we found for creating a Blackberry
-
only application. There is a JDE IDE
available from Research in Motion (RIM). That application is guaranteed to work wit
h the
Blackberry API since RIM wrote it. However, the shortfalls of it are that it has the look and feel of
a poorly written Java Swing application. The controls are not what Windows users have come to
expect. Also, the JDE is difficult to learn and get

started using right out of the box.

RIM has created a plugin for the popular Eclipse IDE which is supposed to allow a developer to
compile their Blackberry project while using Eclipse. On a scale of 1
-
5, 5 being the highest, I
would rate the Blackberry E
clipse plugin a 3 on the scale.
The problem is that it is instable and
seemingly has yet to reach a mature, stabile build
. The quirkiness of the plugin makes it too
difficult to use regularly. First of all, getting the plugin to recognize that you are t
rying to create
a Blackberry project is difficult because the menu item remains grey and disabled until you create
your first Blackberry project. The only problem is that there are no specific steps for you to follow
to do that. The next thing is that th
e compile operation does not always complete. Typically,
Eclipse will perform a build whenever the developer saves a class file. However, with the
Blackberry plugin, that’s not always the case. It is truly frustrating to make various changes to
your cla
sses and deploy them, only to find that they do not include your latest updates. Finally,
the other problem that we experienced was sometimes the plugin would simply delete your project
from your Eclipse workspace. This problem happened for all of us at
various times and the fix was
to create a new project with the same name.

Build Scripts

Since we experienced so many problems with building the application and getting proper updates,
we found what several others before us had experienced. That was build
scripts could solve the
problems with the plugin.
Using an open
-
source project called Blackberry ANT Tools that we found
on the SourceForge web site (
http://sourceforge.net/
), we were able to using the ubiquitous build
tool ANT to perform our Blackberry b
uilds for us. This gave us a confidence that we did not have
while using the plugin. It also provided us with some other nice features like code signing to
deploy the application to an actual Blackberry device.

Database and Hibernate Development

SWENG500
-

Group Report

Best Practices

Error! No text of specified style in document.




March 15, 2013

/
Page
10

of
11

© 200
9,

Confidential & Proprietary



While wo
rking with database code, there are usually two main problems trying to execute SQL
statements. The first is trouble associated with trying to capture a SQL command in code. Many
times, developers find that they must build a SQL command using a series of

string objects. This
usually causes problems with syntax errors when executed on the database because there was
some typo that caused the SQL not to be executed.

The second problem concerns memory leaks
when connections are not closed properly. These a
re the main hazards when working with
database code. So, rather than experiencing these problems, we decided to use an Object to
Relational (ORM) tool to work with our database objects using the API rather than SQL code.

We
decided to use Hibernate since

we had some experience with the product previous to this course.
We would definitely recommend using a tool like Hibernate because it handles most database
operations by using the API without a lot of effort. Once you have the mapping established you
do
n’t need to worry about missing a column of mistyping a column name in the SQL.

Development Process

There are many different components to this project. And, it lends itself well to a group of
developers working on it because each developer can work on a
different component at the same
time. The process that worked well for us was a bottom
-
up approach. First, we considered the
functionality that we were trying to achieve.
Then, we created a stub class to support our
functionality and write a JUnit test
that would invoke our new method.
Then, we started working
on the data model that we needed for the function. Once we modeled it out with a tool, we could
generate SQL code to actually build the appropriate tables and columns in the database.

With our
d
atabase updated, the next step was to update our Hibernate mapping file that mapped our Java
class to the database table. With the mapping in place, we needed to write our minimal Java code
for performing the operation on the data.

So, now we could make
sure that our database code
was doing everything that necessary by continuing to execute our test.

Now that the database code was in place and tested, we could move along to the web service
creation. We started by updating the WSDL file with the PortTypes

to support our operation as a
web service.

We used the code generator to build our generated web service code to support the
remote calls required for the web service. The generated code also included an interface that we
needed to implement that was ca
lled

when the web service was executed.

With our web service in

place, the next step was to create a test that performed the remote calls of the web service.

Once the database and web service pieces were in place and tested, it was time to start working
o
n the Blackberry screens and how they needed to invoke these other layers. After we got to that
point, it was just a matter of trying to figure out the Blackberry API since the other parts were
already complete.

Debugging

While working with any system, it
’s important to be able to debug your code in order to
troubleshoot different issues that arise. The Blackberry gives you to places to see the output of
your debug messages. The first is by turning on somewhat of a status bar that can appear at the
botto
m of the Blackberry simulator. It’s not terribly useful because the text is very small and
flashes messages quickly. A better alternative that is not obvious is to use a secret key
-
combination to unlock the Event viewer. In order to do that, the person
just needs to click Alt
-
lglg
on the simulator or phone. Using this feature allows you to see messages that you’ve added to
your code.

Another thorough method of seeing debug logs is to use the Eclipse debugger tool. If you execute
the Blackberry simulato
r using the Debug option in Eclipse, you can set breakpoints in your code
SWENG500
-

Group Report

Best Practices

Error! No text of specified style in document.




March 15, 2013

/
Page
11

of
11

© 200
9,

Confidential & Proprietary



and use the Eclipse debugger to troubleshoot your code. One drawback to this approach is that it
is often very slow to launch and step through your code to see the issue.

Web Servic
es

For a regular Java application, Apache provides a product named Axis2 to generate Java code from
a WSDL file. The only problem is that it doesn’t build classes that are compatible with mobile
devices. Since Blackberry supports the J2ME web services st
andard, you can use any IDE to
generate the web service so long as they are compatible with J2ME. To do that, we used the
Netbeans API rather than Eclipse because Netbeans already contains a wizard for generating J2ME
web service code for a J2ME device.
We used this tool several times when we needed to rebuild
our code using an updated WSDL.

Another issue that came up with Web Services was a bug where nillable elements were still
required. In order to overcome this issue, the best option is to return an
empty string rather than
nil. If we would return a web service call with only one element that had a nil value, the
Blackberry device would throw an error and the web service call would fail.