In short...I have about 2000 customers by company deals with. Pricing calls consume about 70% of my customer service time on a daily basis. I would like to (although im a total developing noob) some how allow a log in on my Android/ios app that would than allow them to see their specific pricing. Any suggestions?

Do you have that customer data stored in a MySQL database or a .xml file or something? And do you have it up on a server?

MySql, yes. But not hosted anywhere. We do have our own servers...so hosting isn't an issue.

Well it sounds like you'll need to higher a dev to make a custom plugin for your app.

Possibly

Any other suggestions? Would like to learn myself...just looking for a little direction.

Sure, if it's mysql, you'll need to use C (the language) and the sqlite framework inside your custom plugin to access the mysql database. After that it's just making your plugin. Here's some documentation for SQL http://sqlite.org/docs.html they're tons of tutorials on how to use the sqlite framework online. A quick google search should help.

If you are trying to connect the mobile app to your MySQL database, then tune into this webinar on Thursday or watch the recorded video a few days later. The distinguished David Book will be teaching us techniques for connecting BuzzTouch apps to server data. Integrating Apps with a SQL Database: http://www.buzztouch.com/forum/thread.php?tid=A94F3633DDD9189CCC3105C&fid=7BD14758D219B687103E4E3&sortColumn=FT.id&sortUpDown=DESC&currentPage=1

The info is much appreciated!

Super excited for that webinar as well. The biggest challenge is trying to develop screens that work on BOTH platforms - so you don't have to do the same work twice.

@ATRAIN -- I have two thoughts on your quandry of having to maintain two screens, one for desktop web and another for mobile web. 1. Use WordPress + a Mobile plugin to auto-render views for web and mobile. However, one will still have to maintain a mobile theme and a desktop web theme. Alternatively, make a responsive theme that changes the layout according to the screen size of the browser. Either way has its headaches and benefits. 2. Use the Server database to hold that data and the Server code to display views to the desktop web. The Server also generates JSON files for consumption by the Mobile app. This assumes the data does not change often. That approach allows for caching of the data for offline use. Alternatively, the server API can generate a JSON stream of data -- which then would not be cached inside the mobile app for offline use. Either method should be able to take advantage of the built-in BuzzTouch capabilities without having to create new functionality. We shall find out what David Book is thinking on Thursday!

^ indeed, that's the right approach for web/mobile. I love WP Touch, have the PRO license and use it in some apps to do news and calendar "feeds". and those 'screens' are just utilizing the CustomURL plug-in for ios/Android and pointing to mobile optimized content. What I'm thinking David might build here is a iOS specific (or maybe Android) screen with a table view to display the SQL data. That's great but you have to build one for iOS AND then Android. I'm trying to steer cleer of building "native" screens for this stuff so that I can use the same work for both platforms.

An alternative to "native screens" is to use jQuery Mobile screens, which allows for 90% cross-platform compatibility. The real question with BuzzTouch is "When to go native?". For me, the answer is I choose native if it is available in BuzzTouch, via the Core or through a cross-platform plugin. For example, if one person makes an iOS/Android native plugin(s) that is flexible to show server data, then the world can benefit by going native for that functionality. Let the brainstorms ensue! :-)