Maybe its documented somewhere and its just me, maybe its common good practice which I have ignored, maybe its due to the fact I hate reading instructions but I have run into constant trouble porting my app over from iOS to Android. I have created alot of extra work for myself that could have been avoided had I known issues (planned better!) earlier so perhaps its worth adding common issues/errors and problems to the getting started document so that future BT members can avoid the same mistakes I have. Little things such as incompatable plugins causing eclipse errors valid characters (no capitals, hyphens etc)

Many folks in here go down the route of building two separate apps, seems to take away some of the common gotchas. What issues did you have with the plugins? How about you do a quick write up of the obstacles you encountered, would be a nice addition to the FAQ's. It's a learning curve, that much is true but BT gives you the power to build apps like nobody else, it's constantly changing and evolving, putting more power in our hands. Did you think this time last year you'd be a published app developer? Hope you got it all sorted buddy. Best of luck.

@Bass Professor: For sure there's a steep learning curve to all of this stuff. Especially when tackling both iOS and Android at the same time. @MacApple brings up a good point about doing tow different apps, one for each platform. As far as a Common Pitfalls documents, most of the trouble folks run into when going from iOS to Android is related to the compiling process. Eclipse is not an easy IDE, that's for sure. @GoNorthwest has created a great guide to get folks going - it's in the How To's "incompatable plugins causing eclipse errors valid characters (no capitals, hyphens etc)" If this type of issue is happening, for sure the plugin need updated. None of the plugins available on this site have this problem, not sure which ones you're using. I agree with @MacApple in that if you could create a list of the things you think would be helpful to "document" a PDF wouldn't be too tough to create.

The biggest thing that I think would make designing for two platforms at one possible is to adhere to the file and image naming conventions that Android requires. Apple seems to allow pretty much anything with respect to that, where Android has the a-z0-9 restrictions, and no spaces or special characters. If you follow that from the beginning, you won't have any issues with files on either platform. I started an app with Apple in mind, using "normal" filename conventions, and then had to redo them all to adhere to Android's draconian rules. Mark

I know a ton of people have problems with the menu list advanced plugin, with capital letter file-names. Android is a tough one. I would do exactly as @MacApple suggested, create a separate application for android, that's the best route to go in my opinion! It works for me perfectly - it's a pain trying to "port/convert" the iOS designed version. Maybe some people here will be able to contribute some problems and we can all help compile them for new documentation. Would be fun and useful, and I'm sure would help a ton of new comers out. Cheers, David buzztouchmods.com

The best way to do it is to work on both the iOS and Android simultaneously. If you wait until one is done to start the other, you will have a lot of rework. I haven't handed off content management to a client yet, but plan to do so soon. To hand off content management, it is better to have one BT project for both Android and iOS. If you plan to keep control of content, then it doesn't take long to copy the content over to a new project. My two cents.

Yes, I am at a crossroads on whether to keep simulantious builds or indeed start a clean Andriod project. Ive almost got it working but if it ends up compramising on the quality of the iOS app then I will start over. I have around 400 screens in total so its no small job via the web control panel! My main problem was that I didn't really plan out the development process, my project requirements the possibilities, limitations of both plaforms I just jumped straight in to the Xcode deep end! Lots of great advice here @SusanMetoxen "The best way to do it is to work on both the iOS and Android simultaniously" - I agree 100%, infact im sure I read somewhere that BT recommends you download the sourcecode straight after uploading app icon. For sure this would have made life easier @GoNorthWest "Apple seems to allow pretty much anything with respect to that, where Android has the a-z0-9 restrictions, and no spaces or special characters. If you follow that from the beginning, you won't have any issues with files on either platform" - This was a major obsticle for me and I won't make the same mistake twice! @David "incompatable plugins causing eclipse errors" - was relating to the advanced menu plugin (which to be fair does say iOS only). I think a filter in the plugin page would help here long term @MrDavid "Maybe some people here will be able to contribute some problems and we can all help compile them for new documentation. Would be fun and useful, and I'm sure would help a ton of new comers out" - Sure this is the reason for the post, so that others can avoid the same mistakes @MacApple "It's a learning curve, that much is true but BT gives you the power to build apps like nobody else, it's constantly changing and evolving, putting more power in our hands. Did you think this time last year you'd be a published app developer?" - Nope! nor did I think I would have BT running on my own webserver :)

Image or file names in Eclipse can't use upperCase Letters, spaces, " - ", or special characters. So don't use them in iOS for ease of use in Android. Actually the restriction is to items that are compiled, so items in the Assets folder are OK, but it's not a good practice to use them. Fred

Because of client handoff, I need to have both the iOS and Android versions of the app running from a single app in the control panel. I feel I am on the right track, except for one area of confusion: iOS image names follow a convention of "name" (for 1x), "name@2x" (for 2x) and "name@3x" (for 3x). But Android won't allow the "@" symbol. How can I have an array of multiple resolutions of the same image, named in such a way as to be usable by both platforms? If I rename for Android in the control panel, I break iOS, right? And vice versa. ? Is the aim of the BT model to overcome this by hardcoding "large device" filename that eschews the standard iOS practice of "@2x" and "@3x"?

Hi Doug, I think if you name for Android, it'll be good for iOS, which is much more forgiving. As I'm sure you've discovered, Android doesn't allow special characters, spaces, etc. It's best to use all lowercase and numbers. iOS doesn't care, so as long as know the mapping from Android to iOS, you should be OK. Mark

Thanks!

Hi, Doug! This post is a few years old, and in the meantime I have made many apps with one project for both iOS and Android. It is definitely the way to go, although my old advice stands about not waiting until the end to work on both--work on both at the same time. For Android, don't include the @2x and @3x images. Just delete them as they are not necessary to the Android project and will cause an error. For Android you do have extra step of resizing your images in the drawable folders. That is how Android uses different file sizes for different devices. Here is an article on it: http://www.androidwarriors.com/2015/07/android-studio-drawable-folders.html

Thanks, Susan. What I was thinking about doing was renaming my @3x and @2x images so as to be compatible with Android, and using them in the various drawable folders. My confusion is on the three different "methods" I see for an array of different resolution images of the same name. 1. The BT method (array of two: file name for small device, another file name for large device) 2. The iOS method (array of three: filename, filename@2x, filename@3x, but can be named otherwise) 3. The Android method (array of three, in separate drawable folders, but what about naming? must they all be the same name?) Notice my central confusion is about the Android method's naming. Must the resized versions of an image in the drawable folders all have the exact same name? If so, I am having trouble realizing how either of the other two methods are able to coincide with the Android method. Also, if the Android method is keying off of only one of the two BT filenames, which one is it? Thanks in advance if you can shed any light! PS: I am reading the link you shared ... now.

The Android images must all have the same name in the drawable folders. But you can use two different images--one for smartphones and one for tablets, in which you would have two images in each folder. Also, I should mention that when you want to develop for both iOS and Android (or for Android at all) it works best if you don't try to do a design that is specific to a certain aspect ratio. So for backgrounds I generally either use something abstract (set to stretch to fit) or a very small image I place in the bottom right corner.

Susan I read the link, and though it did not really say in clear terms, it implied that the various resolution files in each drawable folder all need to have the same file name. If that is the case, can you help me understand your approach to a single BT app that "controls" both the Android and iOS versions of the app? What do you put into the BT options for "small device" and "large device" file names? Same in both? How does this related to iOS? Sorry to be such a newbie. PS: My reply and yours crossed in the Ether space. Still curious about what you put in BT project settings for small device and large device filenames...

Yep--that is the hassle of Android. You really need to use the drawable folders, especially to avoid upscaling. However, sometimes I cheat and put all the same images into the folders without the hassle of resizing them, and it works sometimes. The small device and large device file names go into the Buzztouch control panel. Not every option on every plugin allows separate images for a small and large device.

Susan: So, if I put into the BT control panel two filenames, one for small and one for large, which one does the resulting Android download package key off of? The large device file name or the small device file name?

That's a good question. It splits based on the pixel width of the device--I believe it splits at around 700 but I can't remember the exact number.

Susan I think you're reading my question as a different question. Let me try restating it. For Android, the "splitting" decision is between a folder choice, not a file naming choice. If Android uses only one file name, it cannot be (or ought not be) "picking and choosing" between two filenames in my BT project. For its various needed resolutions, it is using the same filename always, but "splitting" between which folder it uses that file from. So, my question is, which of the two BT options (large device / small device) is it using to obtain the one file name it is going to go with?

To put it another way: If the BT code that Android uses, really does include -- and use -- both BT filenames (large device and small device) than I don't really have to use the "various" drawable folders... I can just include the two files (large and small) in a single drawable folder, which means I don't have a naming dilemma. Yet if Android is not paying attention to both of the BT "large and small" filenames, and only uses one file name for more than one resolution, I must use the various drawable folders, and I then have a file name dilemma.

What my question really boils down to is threefold: 1. Does Android Studio pay attention to both of BT's "small device" and "large device" filenames or not? 2. If it does not, which one does it pay attention to? 3. If it does, then can't I just ignore the various drawable folders for different resolutions, and just include my two "small device" and "large device" files in a single drawable folder, each having a distinct filename?

One way to answer this question definitively is to to create two Android emulators - one that would qualify as a small device, and another that's a large device (like a tablet) - and watch LogCat to see which image it picks when. Then the question would be answered completely! Mark

Excellent idea. Thanks!

In order for me to do that, I would need to get past the 115 errors that have kept me from successfully building. Still working on that.

The Android pays attention to what you set as both the large and small device images on the Buzztouch control panel. That is what I meant about it splitting at 700 pixels. If the screen width is less than 700, then it shows the image you entered for the small device. If the screen is 700 or more, then it shows the image you have for the large device. The only thing I am not sure of is what that number is--700 come to mind, but it may be 800. With that in mind, if you have two different images for large and small devices, then you need to put them both in all the drawable folders.

Susan, That is good news to me about Android paying attention to the two file names. Re: "if you have two different images for large and small devices, then you need to put them both in all the drawable folders." You have much more experience than I on apps in general and Android in particular, so I hesitate to disagree, but I would point out, based on both the fact that there are images from BT in only the main drawable folder (and not in the size based ones) and my long history with programming/coding, that there is not any need for two ways to solve the same problem. Since the Android system pays attention to the two filenames, I would expect that placing the two files in only the main drawable folder will be sufficient. I aim to try to confirm that theory as soon as I can. Thank you SO much for being so kind in answering. Your help, and that of others here, has already been invaluable.

Buzztouch may provide a means for serving up an image based on screen size, but the different res > drawable folders also allow for different screen densities. You find in your testing that if you only provide images in the res > drawable folder, that sometimes you'll get an out of memory error if the image has to be expanded to cover a different screen density. It's happened to me countless times, and I've worked around it by including the same images in all of the folders. Here's some good reading on the subject: http://developer.android.com/guide/topics/resources/providing-resources.html Thanks! Mark

Thanks Susan and Mark. Mark, you definitely helped me realize that Susan's advice was indeed needful to heed. Me hesitation in disagreeing was warranted. I just did not hesitate long enough. :-)

Android is a pain to develop for to start, but once you understand all the caveats, it goes like all the rest. Keep the questions coming! Mark

My problems on the Android side are diminishing.... Remaining issues, by order of "crucial" to "annoyance" ======================================================================== BT PUSH (on self hosted) is crashing the Android app when the message is received. ======================================================================== I have followed all the steps shown here: <a href="http://www.buzztouch.com/forum/thread.php?tid=56643342D49BA08BDEEB1EF" target="_blank" rel="nofollow">http://www.buzztouch.com/forum/thread.php?tid=56643342D49BA08BDEEB1EF</a> ... and an incoming message gets displayed, but immediately crashes the app. ======================================================================== Android: Map not zoomed to correct level ======================================================================== I found a post by chris1 at: <a href="http://www.buzztouch.com/forum/thread.php?tid=E6C574550BEB93E9863E6E7&fid=0B19EC7C02CBDD92F12FD08&sortColumn=FT&sortUpDown=&currentPage=1" target="_blank" rel="nofollow">http://www.buzztouch.com/forum/thread.php?tid=E6C574550BEB93E9863E6E7&fid=0B19EC7C02CBDD92F12FD08&sortColumn=FT&sortUpDown=&currentPage=1</a> It refers to editing code presumably in BT_screen_map.java, however, the function there has changed name since his post, and the terrain of the code looks rather different and I am not yet sure where to add his code, or whether to. ======================================================================== Android: "HTML docs" ignore linked CSS and ignore linked images ======================================================================== Not sure what's up there. ??? ======================================================================== Android: "HTML docs" don't display like they're inside the app. ======================================================================== Big "download document" button, big "open document" button, big "html" icon, and then what looks more like a native browser that shows the URL in a "browser bar" at the top. Really wanted it to be like the iOS version where the URL serving the content is hidden and the download happens automatically with a little "spinner" or progress indicator. I have noticed that on Android, the "Custom URL" plugin seems to function more like the "html Doc" plugin does on iOS. I am supposing I could switch away from "html Doc" plugin to "Custom URL" -- but my understanding (from reading here on site) was that "Custom URL" does a new fetch always by design, and I wanted caching functionality. ======================================================================== Android: Layout Tabs are way too wide. ======================================================================== Java says width should fit content or some such. They are just 4x to 5x wider than they need to be. Height is fine, just the width is too much. ??? I should add, I am using the AMG Button Plus plugin, thus I am looking at AMG_ButtonPlus.java