I started the day today, excited about reviewing Plugins to add to my Map App. Then, that crashed with a thud, as most of the Plugins are either/or, iOS or Android... most are not iOS AND Android. I want to offer my Map App as both iOS and Android. Is iOS and Android moving too fast or too slow, in parallel or divergent directions, for Plugin developers to keep up with?

It's a common complaint that Android isn't matching iOS in plugin numbers. My argument (as a plugin developer) is that Android is advancing, but not quite as fast as iOS. I know that it can sometimes be a bit difficult that there is an Android plugin and a separate iOS plugin that does the same task, however, there are ways round the problem. 1. You can create two projects, one for iOS and one for Android. There are advantages to this, as you can optimise anything in the app to look more appropriate with each operating system. 2. Chris's plugin (Menu Image Advanced) lets you elect a different screen according to the operating system. Let's say there are two weather plugins (one for iOS and one for Android). With Chris's plugin, you can set the same menu row to go to the Android plugin on an Android phone, and to go to the iOS plugin on an iOS device. This is the most straight forward method, and the recommended one.

Having said that, there are still quite a lot of dual plugins. I can explain why it's more complex to merge two operating systems into one (instead of having two plugins) but that would be the length of a book and would tire you out!

I don't mind making two versions of my Map App... the tough part is trying to stay on top of WHEN an Android developer might add, e.g., geoFences or iBeacon. I wish both of my iOS and Android Apps were the same, in terms of features. It is going to be a constant process on my side, to watch and wait for the add'l plugins - perhaps for both iOS vs Android, a constant see-saw or leap-frog, to keep the one up to the other. I was kind of hoping that I could develop both simultaneously. My first clue was last week, when Menu Simple was creating solid color menu rows with color text, as the code expected, but Android ignored that, and left them as transparent rows with grey text. I'm still hoping someone can go fix that. Susan hinted last night. BT-Self Hosted V2.0 worked for Android with solid rows... BT-Self Hosted v3.0 isn't (transparent, grey text). Perhaps it has something to do with the current Android, perhaps something in creating the BT-Self Hosted 3.0... perhaps a combo plate. BTW - iOS is now 7.1 with 8 on the horizon. What is the official term for the current version/target/?? for Android. So we're all speaking the same language here. And seriously, what IS current, for Android - and when? iOS 7 (7.1?) was Oct(?) 2013. iOS 8 looking to be Oct 2014? What are the benchmarks for Android?

Funny you should ask about android. This popped up on arstechnica today. http://arstechnica.com/gadgets/2014/06/building-android-a-40000-word-history-of-googles-mobile-os/ BT 3.0 works well with any android version 4.0+.

Finding things that work on both platforms is a toughie; Thomas has produced the most likely scenarios for you... I also utilize Chris' MWI Advanced for the platform 'selection' feature. It enabled me to use distinctly different plugins for the same feature on both app 'versions'. That said, if you want to duplicate features (like I do) on all plugins, you might need to roll up your sleeves, and dive into Android Development, which is where the talent needs to focus. Although BTv3 Android 'works' with Android v3, we 'compile' using Android v4, API 14. I released a couple of iOS 6 apps about 3 months after the release of iOS 7... no problems from Apple on that. I doubt though, that it would work 'now'. Cheers! -- Smug

It looks like I'm 4.3 API 18. Do you think that's why my Menu Simple menu rows are transparent with grey letters, when on iOS they are solid black with gold letters - as per the code? If I drop down today to make that work, what happens in a few weeks when the users are at 19?

Well, I think all my android apps published are BTv2, at Google API v2.2, and they work just fine on Android devices; I'm not too worried about 'not catching up' with them. I'm more concerned with the devices 'out there now'. If you 'compile' with API 18, and don't modify your AndroidManifest, then you may limit users to those with API 18... The bottom line is compatibility. I want my app to be applicable to the most users possible. Android has been releasing updates every 2 minutes since it's inception, yet most hardware producers are 'just' getting around to cutting off API 8, and API 14 is becoming the new 'baseline' of the minimum Android version needed to run BT Apps. I'd suggest getting API 14 (Android, Not Google) and using that for compilation. The Manifest states that (although we compile for v4) Android v3 is the lowest version capable of running our apps. I haven't done any snooping into the differences in Menu versions, but it's possible that while updating the code, some details may have been missed. It sounds weird, but it's easier than you think. Android is an 'odd bird' when it comes to development. Cheers! -- Smug

Just saying. I always build two. Makes updates etc easier and can add new features as and when requires. Makes things easier. Still think is is very and easily possible to make cross platform with one version if you tweak lil bits of code but for me and the way I operate 2 is the way to go.

Remind me again, how I pick the API version in Eclipse, so I export the correct .apk? I just installed API 14. I had 19. How do I tell Eclipse which to use?

OK, I found it in Preferences. Going for 4.0 API 14.

Running Simulator... still Gold Letters on Transparent Rows. I'm with ya, that maybe Self Hosted v 3.0 maybe missed something in Android. But I have been talking about the transparent menu rows for over a week.

That, and I'm trying to remember which application I used to create my Gold/Yellow gradient Icon!!! Turns out, it wasn't my favorite (Apple Pages). Oh, I hope it wasn't PS. I get such a headache using PS.

Well, see, it's not 'self hosted' that is missing anything. The 'biggest' difference between self hosted and BT hosted is... well, one is hosted by you, the other is hosted by BT. There is no 'code difference' in your project. If you built the same project in your BT hosted account, I suspect you'll still have the same issues. When you're ready to download your project, Self/BT Hosted will 'reach' into another BT server to obtain the code to prepare your package, and provide it to you. However, a lot of backend magic is going on between your 'control panel' (regardless of where it lives) and the BT 'back end'. "That" is the code that (may or may not) need updating. If you have Chris1's 'Menu With Image Advanced', you can configure it with the same properties as a menu simple; Chris has far less on his plate than David (I 'think') and may have addressed these issues in his plugin. I know his Android version is probably the most advanced menu I've seen for the platform; he created XML layouts for every possible scenario, including a 'menu simple' style. Cheers! -- Smug

But my v2.0 App for Android had solid black rows, as v3.0 iOS does. Before I start buying a lot of plugins, and Chris1's are pricey, I want to make sure I understand how to get them to all work together. David may be busy, but is there a consolidated location where he looks for bug or discrepancy reports?

Lol! Yep. Chris's plugins are pricey... until you consider how much time it took him to build it, or how much time you'll save over creating it yourself. But I understand what you're saying; why buy a tool you don't know how to use? Make sense. When you do get around to shopping, I can say with authority you won't waste a dime with Chris' plugins. Or Susans, from which Chris based his work. And Susan based her work on David. I base a lot of my work on work they've already done. I don't have a plugin out there that doesn't share at least a smidgen of their code. But I digress... Honestly, I rarely bother with issues with the 'default' plugins, because the features of the other choices usually are much more attractive. When you do make your purchase decision, I'm sure that it will exceed your expectations. Cheers! -- Smug With respect to getting David's attention, he usually refers to the list Chris1 keeps on his site. https://www.buzz-tools.com

For me, the features of a plugin is worth the cost of investment. It also allows you to tinker with the code by changing color, width, spacing, etc -- all the while learning techniques. Lastly, it's a way for me to buy that plugin developer a cuppa or two. :-) -- Niraj

I am very concerned about buying a tool that might conflict with other tools. I have indicated to Plugin developers that I might be interested in their Plugin(s), but none have engaged in conversation regarding making it fit. e.g. Niraj's Cubby Holes. I have written to Chris1 and Susan. Lack of constructive conversation before the sale, can mean lack of care after the sale. First, I want to get to the bottom of David's Menu Simple not doing solid color rows in Android. Self Hosted v 3.0.

All resolved https://www.buzztouch.com/forum/thread.php?tid=39EFAAD07B4E8B268D026D9&sortColumn=FT.id&sortUpDown=DESC&currentPage=1 Thanks to @AlanMac and @Chris1