Joel R. Kallmanhttp://firstname.lastname@example.orgBlogger167125
Updated: 5 hours 52 min ago
As the release of Oracle Application Express 5 gets closer, I thought it's worth pointing out some changes that customers should be aware of, and how an upgrade to Oracle Application Express 5 could impact their existing applications.
- In the rewrite of Interactive Reports, the IR component was completely revamped from top to bottom. The markup used for IRs in APEX 5 is dramatically improved: less tables, much smaller and more efficient markup, better accessibility, etc. However, if you've also followed this blog post from Shakeeb Rahman (@shakeeb) from 2010, and directly overrode the CSS classes used in Interactive Reports, that will no longer work in IRs in APEX 5. Your custom styling by using these classes will not have any effect.
- As the Oracle Application Express 5 Beta documentation enumerates, there is a modest list of deprecated features and a very small list of features which are no longer supported. "Deprecated" means "will still work in APEX 5, but will go away in a future release of APEX, most likely the next major release of APEX". In some cases, like the deprecated page attributes for example, if you have existing applications that use these attributes, they will still function as in earlier releases of APEX, but you won't have the ability to set it for new pages. Personally, I'm most eager to get rid of all uses of APEX_PLSQL_JOB - customers should use SYS.DBMS_SCHEDULER - it's far richer in functionality.
This is an example of a real-world problem, an opportunistic one, being solved via a mobile application created with Oracle Application Express.
First, a brief bit of background. Our son is 9 years old and is in the Cub Scouts. Cub Scouts in the United States is an organization that is associated with Boy Scouts of America. It's essentially a club that is geared towards younger boys, and teaches them many valuable skills - hiking, camping out, shooting a bow and arrow, tying different knots, nutrition, etc. This club has a single fundraiser every year, where the boys go door-to-door selling popcorn, and the proceeds of the popcorn sale fund the activities of the Cub Scouts local group for the next year. There is a leader who organizes the sale of this popcorn for the local Cub Scout group, and this leader gets the unenvious title of "Popcorn Kernel". For the past 2 years, I've been the "Popcorn Kernel" for our Cub Scout Pack (60 Scouts).
I was recently at the DOAG Konferenz in Nürnberg, Germany and it wasn't until my flight home that I began to think about how I was going to distribute the 1,000 items to 60 different Scouts. My flight home from Germany was on a Sunday and I had pre-scheduled the distribution of all of this popcorn to all 60 families on that next day, Monday afternoon. Jet lag would not be my friend.
The previous year, I had meticulously laid out 60 different orders across a large meeting room and let the parents and Scouts pick it up. This year, I actually had 4 volunteer helpers, but I had no time. All I had in my possession was an Excel spreadsheet which was used to tally the orders across all 60 Cub Scouts. But I knew I could do better than 60 pieces of paper, which was the "solution" last year.
On my flight home, on my iPad, I sketched out the simple 4-page user interface to locate and manage the orders. As well, I wrote the DDL on my iPad for a single table. Normally, I would use SQL Developer Data Modeler as my starting point, but this application and design needed to be quick and simple, so a single denormalized table was more than sufficient.
Bright and early on Monday morning, I logged into an existing workspace on apex.oracle.com. I created my single table using the Object Browser in SQL Commands, created a trigger on this table, uploaded the spreadsheet data into this table, and then massaged the data using some DML statements in SQL Commands. Now that my table and data were complete, it was now time for my mobile application!
I created a simple Mobile User Interface application with navigation links on the home page. There are multiple "dens" that make up each group in a Cub Scout Pack, and these were navigation aids as people would come and pick up their popcorn ("Johnny is in the Wolf Den"). These ultimately went to the same report page but with different filters.
Once a list view report was accessed, I showed the Scout's name, the total item count for them, and then via a click, drill down to the actual number of items to be delivered to the Scout. Once the items were handed over and verified, the user of this application had to click a button to complete the order. This was the only DML update operation in the entire application.
I also added a couple charts to the starting page, so we could keep track of how many orders for each den had already been delivered and how many were remaining.
I also added a chart page to show how many of each item was remaining, at least according to our records. This enabled us to do a quick "spot check" at any given point in time, and assess if the current inventory we had remaining was also accurately reflected in our system. It was invaluable! And remember - this entire application was all on a single table in the Oracle Database. At one point in time, 8 people were all actively using this system - 5 to do updates and fulfill orders, and the rest to simply view and monitor the progress from their homes. Concurrency was never even a consideration. I didn't have to worry about it.
Now some would say that this application:
- isn't pixel perfect
- doesn't have offline storage
- isn't natively running on the device
- can't capitalize on the native features of the phone
- doesn't have a badge icon
- isn't offered in a store
And they would be correct. But guess what? None of it mattered. The application was used by 5 different people, all using different devices, and I didn't care what type of devices they were using. They all thought it was rocket science. It looked and felt close enough to a native application that none of them noticed nor cared. The navigation and display were consistent with what they were accustomed to. More importantly, it was a vast improvement over the alternative - consisting of either a piece of paper or, worse yet, 5 guys huddling around a single computer looking at a spreadsheet. And this was something that I was able to produce, starting from nothing to completed solution, in about two hours. If I hadn't been jet lagged, I might have been able to do it in an hour.
You might read this blog post and chuckle to yourself. How possibly could this trivial application for popcorn distribution to Cub Scouts relate to a "real" mobile enterprise application? Actually, it's enormously relevant.
- For this application, I didn't have to know CSS, HTML or mobile user interfaces.
- I only needed to know SQL. I wrote no PL/SQL. I only wrote a handful of SQL queries for the list views, charts, and the one DML statement to update the row.
- It was immediately accessible to anyone with a Web browser and a smart phone (i.e., everyone).
- Concurrency and scalability were never a concern. This application easily could have been used by 1,000 people and I still would not have had any concern. I let the Oracle Database do the heavy lifting and put an elegant mobile interface on it with Oracle Application Express.
This was a simple example of an opportunistic application. It didn't necessarily have to start from a spreadsheet to be opportunistic. And every enterprise on the planet (including Oracle) has a slew of application problems just like this, and which today are going unsolved. I went from zero to hero to rocket scientist in the span of two hours. And so can you.
A demo version of this application (with fictitious names) is here. I left the application as is - imperfect on the report page and the form (I should have used a read-only display). Try it on your own mobile device.