Monday, November 28, 2011 at 1:29PM Using an API and want to set something to null??
Will not work
p_SERIAL_NUMBER => null,
p_TRANSACTION_UOM => null
Will work
p_SERIAL_NUMBER => FND_API.G_MISS_NUM ,
p_TRANSACTION_UOM => FND_API.G_MISS_CHAR
Tuesday, November 15, 2011 at 8:56AM It great to see all the support for mobile development coming in apex 4.2, as well as all the demos/presentations/tutorials from the Apex community. Its a growing space and Apex is right out there riding the incoming wave.
Butall is not well in mobileland...one of the biggest omissions I am seeing is not the how, creating a template is quite simple, but in the why and what.
The Why.
I've been presenting mobile development for a while now, all the way back to Oracle iAS wireless, where we had to screen scrape Yahoo stock quotes and displayed a number on a Motorola StarTAC.(now that was a phone) The biggest hurdle we had when going into customers was the why. Why do I need this? Creating value in the mobile platform extends far beyond templates and pretty transitions. Our mobile apps have to create this value to fill in the why, so that people see these apps and need them. Like a Steve Job's product, create that need where the customer/client/etc didn't even know existed.
The What.
Building on the why the what, or method, needs to be established. Taking an existing app, putting a mobile template up and declaring victory isn't really going to win anyone over as soon as they attempt to use it. Sure it might look pretty, but its unusable. The business side of mobile development is the redheaded stepchild that no one seems to want to address. When building our mobile apps, UX has to be in the back of our minds from day 1. How will the consumer interact with our app? Is there alot of text fields? No one truly likes to type on virtual keyboards, save that youtube guy. So we need to think about our UI elements. Select lists and buttons all work well, as long as they are sized appropriately. Unordered lists work great as well. jQuery Mobile takes these and makes them shine.
Security is another matter. How do we control it from a mobile standpoint? It's alot easier and likely to loose your iPhone than your desktop, so our apps must take this into account. I recommend creating 2 apps to start. A mobile only one and your regular one. This way we can set security as needed. Also set your app timeout on the mobile app to be very short. You leave your phone on a plane and someone picks it up, by that time, the timeout will have kicked in and the app is locked out. How about restricting the functionality of the mobile apps as well? Maybe we can only view info, perform a few button actions, rather then delete and create new records?
Just a few thoughts that extend beyond the template creating that comes with mobile development. The app creation is the easy and fun part, everything that surrounds it is the tricky part.
Wednesday, November 9, 2011 at 6:41PM Here is the presentation from SEOUC last week. Great audience and super conference.
Thursday, May 26, 2011 at 10:27AM Just looked this up and found the answer...you can reference the count of inline form validation errors and use that in a condition display. Now you can just use the select box for (No) Inline Validation Errors Displayed, but what if you want that and something else (not null, 1=2, etc)?
Just add "and wwv_flow.g_inline_validation_error_cnt (<,>,=) x" to a plsql condition/function. Now you can create more complex conditions based on form/page validations!