This is the first time I have really attempted a Project using Firemonkey, with the Target Platform been Android.
I am finding it difficult trying to understand the workflow with the use of views been somewhat trivial, I just can't seem to grasp the concept at the moment.
I have successfully managed to get the Delphi IDE to recognise my device (Xperia Z2) so when building and running the Project I can see the app on my phone (although so far I am not too impressed, long black screens before anything showing and sometimes the app wont show at all, not to mention slow compilation and linking time).
The first problem I ran into is that controls dont appear on the Android device in the correct places. I added Android 5" Phone as a view as that would be the closest thing to my device, the controls on the Form Designer are aligned to how I want them, for simple testing I just dropped a couple of buttons that are centered in the middle of the form horizontally. When running and viewing the app on my phone however, the buttons are wider than the visible area of the phone, I tried the same with other views such as Android 4" Phone and it's the same. The controls appear lined up correctly on the Delphi Form Designer, but when running and viewing them on my phone they are not lined up at all, it feels like I need to guess where the controls should appear making views seem pointless, after all I cannot test on a multitude of devices and therefore if they don't appear on my phone as they do on the Delphi Form Designer what hope do we have? I expected that how the controls appeared in the view window is exactly how it should appear on my Android deivce but this does not seem the case.
The other view related question is, what is the purpose of the Master View? From my vague understanding you need views to design the layout for each Android device, does this mean then for each device view we have to constantly reposition and move controls independantly for each view? What purpose does the master view have, other than from what I can tell you can only delete controls from the master view and from each view use the Revert to Inherited context menu.
It feels like I need to guess where the controls should appear, the device view at Design Time seems rather inaccurate, surely how you look at the device view on the Form Designer is exactly how it should appear on your Android device?
Related
When an app is running in a third of an iPad screen, there is a small drag handle at the top of its window. In iOS 10, dragging on that handle lets you switch what app is open there. In iOS 11, you can use it to change the app from taking up a third of the screen to floating over the rest of the screen.
My question: how do I know when this handle is present, or at least know that there's something taking up that space? I need to lay out my UI content around it without conflicting with it. It doesn't appear to work with iOS 11's Safe Area APIs.
See here for a sample project trying to put a label at the top of a window without overlaying the drag handle. Run it in a third of an iPad screen.
Start by duplicating the radar. This is definitely something that should be handled by the safe area magic.
The issue here is that the handle is rendered by SpringBoard, so you can only apply tricks to guess whether it is currently visible. You can determine whether the window is at the right size and whether it is at the correct location on screen, and then add some extra safe area insets. This is normally ill-advised for several reasons, such as not knowing all cases where the handle appears, having to take into account left-to-right systems, etc., but in this case, the problem seems so egregious, I'm not sure I'd recommend leaving as is.
Edit
One more option is to see if UIWindow.safeAreaInsets returns a correct value. UINavigationController is able to deduce the safe area correctly, so it is hiding there somewhere.
I have issue when I try to push view controller in willTransitionToPresentationStyle:. The view was blinking for a split second before it fully expanded. It might be a small glitch or bug since iOS 10 and Xcode 8 are still in beta. But when I manually requested to change presentation style to MSMessagesAppPresentationStyleExpanded by calling requestPresentationStyle: after I push view controller, it went to expand mode more smoothly. Does anyone have similar issue?
I have had similar problems with transitions in iMessage apps. I think this should improve considerably when iOS 10 and Xcode 8 come out of beta, but for now we have to deal with Xcode's bugs.
There's a few things I've done to make this look better. Inside my extension I have a method that checks the presentation style every time the view changes. This method manages two different UIs - one for MSMessagesAppPresentationStyleExpanded and one for MSMessagesAppPresentationStyleCompact. This method hides and shows specific views accordingly. In my compact UI I have a button that allows the user to expand the interface by clicking it (this is basically the same as clicking the up arrow at the bottom right of the screen).
I've noticed that if you let the user expand the messages app after the view has been loaded for a while the transitions are much smoother and less buggy. Not sure why this is the case, but you should give it a try. Also, I've found segues to be extremely buggy, so that's why I went with keeping everything on one view controller.
One of our Appcelerator apps is experiencing rendering delays on IOS platform for the screens where there are multiple widgets (customised textfields to meet client UI requirement) being displayed inside the scrollview.
The screens are making use of ScrollView where these custom controls (Widgets) are displayed inside the views. We are seeing the delay in the following scenarios:
When the screen is having quite a few controls displayed (around 10-15 controls).
It is observed that the rendering time it takes and any changes to this control properties while the page is loading (such as setting some properties by calling the methods on the widget) is resulting in extra 2-3 secs delay.
When these controls are dynamically added into the page - say in response to the question by the user we display additional controls to capture the information.
We have seen a clear lag in this case which is not good from the user experience perspective.
Note:
All of these issues are only on IOS platform whereas the same code works pretty good (without any lag) on Android platform.
Tried out using the tableview in place of scrollview but the result is no different.
Using tableview also results in poor scrolling performance.
As some complex views are created and added dynamically, using listView would be challenging.
Can anyone let me know if any of you are aware of such issue and how it was resolved (in any appcelerator project)? Is there any way on the native front setting some property/native code through a module that would help speed up the rendering on IOS?
We are only developing for iPads and iPad Minis using iOS 7.1.1+ using Titanium SDK version 5.1.2 (We have tried latest SDKs, but they haven't solved our problem).
Background:
My workflow for developing interfaces for mobile apps depends on Illustrator and Photoshop. I'm not a fan of Interface Builder, nor am I impressed by the Android UI designer in Eclipse (haven't tried IntelliJ yet). It's awkward to take an experience of laying out UI from such apps, and translate into IB. Once in a while I try again to build a UI in IB, only to get bogged down in bad experiences.
The current problem I'm having is this:
When selecting a set of well-laid-out views within a View Controller's view from an iPhone storyboard, and then pasting into the corresponding View Controller view of the iPad storyboard, the views are all messed up. They get thrown all over the canvas, and the size manipulation handles are hidden because they're not within the bounds of the superview.
Is copying and pasting inappropriate behaviour in Interface Builder? Must I drag everything out of the library again?
Side note: I'm working on a 13-inch screen, and the iPad view is larger than the small area given to work with. I zoom out so I can actually see the whole thing, then select a component to adjust it, and find IB automatically zooming back in.
I've found question-answers saying the auto-zoom cannot be disabled, and so I have to just put up with that awkward UX.
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.