I want to develop a Android app with an interface like Viber. Multi pages that user can swipe between them.
How can I do this with Qt and Qt Quick?
Is StackView what I need?
I haven't used Viber on Android but on iOS (and the last time i used it over a year ago) they had a UITabBarController at the bottom which switch between several main screens. The contact screen for example displayed a UITableView wrapped in a UINavigationController so you could select a contact then view the contact's details.
So what you could do is this:
Build a TabBar QML Component and anchor it to the bottom.
Build a Tab Component that's reusable so you can just add new tabs to the TabBar with a method like addTab(Component, string) where Component is your customized reusable Tab component and string is the name of your view's QML file which can be lazy loaded with a Loader.
In your Contacts QML file (or any one that needs a "Master-Detail View") you can then create a StackView and add any required view's as components.
Take a read though this:
http://doc.qt.io/qt-5/qml-qtquick-controls-stackview.html
Definitely also read up on how QML Loader and QML Component work as they'll be the basis for most of this. You might want to experiment with this first in a separate project before getting too deep in the real UI.
Related
I am creating a react native app using expo, and I am creating a dropdown in the header. On iOS the dropdown works as desired, and goes 'above' the main content, while on Android it is clipped or goes 'under'. I am not sure if in reality iOS is acting strange, or Android is.
The header is a custom headerTitle component, which holds the custom dropdown component (a view, which holds the dropdown items (Views with text and icons)
I am looking to get around this issue, and I have tried zIndex and absolute positioning (which I have read does not even work on android, but thought I would try), and that did not fix it (and caused other issues).
Any tips, tricks, and better understanding of why this happens on iOS and Android would be greatly appreciated. I can post code if necessary as well.
React Native does not support overflow: 'visible' on Android.
A good example to look at for this is here: https://github.com/brentvatne/growler-prowler/blob/0eebfaae641a088b1a1fd7ffe552deeac914bffe/screens/BreweryListScreen.js#L70-L76
The key here is to render the menu component inside of a modal (in this case I'm using react-native-root-modal) in order to have it appear on top of the header.
I am using portable Xamarin.Forms (cross platform) having Android and IOS project.
I am using carousel page so that I can swipe page.
I want only middle content should swipe not whole page. header and footer should not be swipe
You can see in below image that whole page is swiping. I want only middle content to swipe
Please suggest me how to do?
You should look at pre-release version of Xamarin.Forms.CarouselView for your use-case:
Nuget: `Xamarin.Forms.CarouselView 2.3.0-pre2`
CarouselView is a replacement for the CarouselPage. and CarouselPage will be marked as deprecated sometime in a future release of Xamarin.Forms.
CarouselView's are virtualized, a huge memory decrease over CarouselPage when dealing with more than a couple of pages and can be used like a "control" within a Page those you can apply header/footer templates to your page and place the CarouselView in the center.
Source: https://github.com/xamarin/Xamarin.Forms.CarouselView
I use listview with horizontal swipe instead of coursal page. it works fine
This is a relatively straightforward refactor using ControlTemplates:
Xamarin.Forms control templates
Presuming you are using MVVM, you would then assign the ControlTemplate to the ContentPage controlTemplate property: e.g.
contentView.ControlTemplate = new SampleControlTemplate()
I personally use GridViews within the ControlTemplate to get a more finite control of the layout. The final output is the area defined as the ContentPresenter will be populated with the layout from your ContentPage (in your case the CarouselPage).
I have simple android app mockup with home screen.
Homescreen contains 3 options: start game, settings and leaderboards.
I am not sure, what alloy components should I use for screens like settings etc.
Should I use different controllers for home, menu, settings etc? Or should they be just different Views in the same window? I can't find information about good practice for titanium app design.
you can take a look this framework: ChariTi-CB
Actually, I will prefer use one window and include all screens, and use the view for each screen, in this way, if you want to control the window style (like the orientationModes), you just can easy to control it in the app. The above framework is use this design pattern.
Well we tend to use a separate controller for each separate piece of functionality. If each controller would be displayed in a separate window then in this case I'd have 6 files:
/controllers/startgame.js
/views/startgame.xml
/styles/startgame.tss
/controllers/settings.js
/views/settings.xml
/style/settings.tss
/controllers/leaderboards.js
/views/leaderboards.xml
/style/leaderboards.tss
just use "alloy generate controller" on the CLI to generate them quickly.
I'm going to port an Android application over to the iPhone platform. I need header-footer like functionality so I'm looking for Android-style layouts merging for iPhone.
Does iPhone support this? If so, how?
[EDIT]
May be above header-footer description creating confusion.I am trying to describe again.
I would like to merge two different .xib file's view in single xib.for an example I have "footer.xib",I just want to include (reuse) same "footer.xib" view in different pages instead of copying same code for each page. I'm very new to Iphone world, so any guidance would be appreciated!
I'd second the notion of going from scratch. I'd question why you'd need header functionality (UINavigationController provides a default header), but with the footer, do this:
Create a subclass of a UIView or UIToolbar or the like, and do custom drawing or custom layout in code. Then, place them in your views by dragging a UIView into a NIB/.XIB view controller file and changing the "Custom Class" field to that of your subclass, or programmatically add them.
I have an Android app that I would like to convert to an Android library. The app is based around one activity whose entire XML layout contains only a webview that covers the entire screen. The library UI (really, just the webview) must now be integrated into the layout of other apps. For example, one parent app has a tab structure. I would like to have the library webview displayed in one of the tabs, with the tabs always visible at the bottom of the screen. Ordinarily, I'd opt to set the app-library boundary at the activity level but that does not work in this case -- we cannot pop up a new Activity from the library because that would cover all of the screen and the tabs at the bottom.
What is the best way to convert this to a library so that it works within the tab structure of the parent app? Where should the app-library boundary be? Some of my ideas are:
Let the library user create an activity with the custom layout that he prefers (tabs in this case). Make sure that the layout contains a webview. Use findViewById to get the webview object and pass this object into the library for the library to use to display pages. Main disadvantage here is that parts of the library need to hook up some Broadcast receivers onto the parent activity (which is not really part of the library in this scenario), and this coupling seems rather dubious.
Perhaps use fragments which were introduced in Android 3.0. However, these mostly seem geared towards tablets. Would these work in this case?
Is there another option compatible with Android 2.1+ that I am not aware of?
I decided to go with Fragments, using the compatibility library.
http://developer.android.com/guide/topics/fundamentals/fragments.html
http://developer.android.com/sdk/compatibility-library.html
Fragments are really the best choice in this case because:
They have a life cycle similar to that of activities, making conversion easy.
They are a chunk of UI with related functionality, which is exactly what's needed in this case.