I created an app for both apple and android that uses a web calendar to schedule and display activities. I need to create a native version of it so users can use the calendar without the need to have access to the internet, but when access to the internet is available it would then update the server database. Can anyone please offer any advice if you think in principle this is realistic using BT or would this be better getting a custom designed app? PS I've been out of the forum for a while and just getting back into it now so would appreciate any assistance thanks.

BT or custom, that's not the issue. If you want data to reside inside the app, there is nothing wrong with that; the BT_Docs (Images, Audio, etcetera) is there to keep things sort of organized. With respect to getting that functionality, there may not be a Plugin available to 'cache' the local data and wait for a connection, but that can be implemented into a custom plugin you write to provide that functionality. What you'll want to do is when the user enters data, have the app check for a network connection and if not present, write it locally. Then have another process check every so often for network availability. If available, upload that saved data... Something like that. Think the process out in your head. Write it down on paper. segment it out into tasks. And go from there. It'll be easier than you think. Cheers! -- Smug

Thanks Smug, appreciate your reply. The other main issue, which to be honest I have never got my head around (I'm not a programmer) is how flexible BT is to create native type functions (for both ios and android), in this case calendar functions to offer user friendly ways to schedule work shifts, vacations, etc and then display these activities on a calendar type display. Any advice? Thanks, Chris

Well, I've found it to be darn flexible, myself. I'm a programmer, but I'm no Obj-C/Java programmer. As far as I'm concerned, I speak swahili and I need Russian. That said, I just finished my first iOS plugin. After pulling my (limited supply of) hair out for a couple of weeks, working on 'native' functionality, I almost gave up. Then I started snooping through the Buzztouch code to see how others did it, and I've come to find out that a lot of the work has been done already; We just have to learn how to access the intrinsic buzztouch procedures. Which is a darn sight easier than doing it all ourselves. And learning how to do that is no more/less/different than doing Xcode (or Android/Eclipse) in any other environment. And the beauty is, all of the knowledge (Android or iOS) gained while programming with buzztouch can be leveraged in either native environment as well. It's really a win-win. But returning to our original conversation... The project may seem daunting, but if you separate it into (a bunch of) small one or two function tasks, you'll find it to be a lot easier to complete, it gets easier as it goes, and you can re-use the functions in other programs. Cheers! -- Smug