Just starting out on android developing. To start off, I'm building an app which is gonna function like a gallery+image viewer, with the added functionality of quickly and swiftly moving pictures into subfolders, for easy sorting of lots of pictures.
So far I have 2 activites - a full screen image view, and a full screen thumbnail grid (for multiselect purposes).
Now as I'm new at this, I was wondering if this dual-activity was a wise decision. Would it be better to simply switch between content views than to power up an entirely different activity when switching from image view to grid view (and vice versa).
What I'm looking for are of course the obvious pros and cons - performance, ease and usability. But also if there are more fundamental "pattern"/best practice reasons for one or the other.
Thanks
I think your dual activity approach is sensible. Generally speaking the Android Activity/View APIs are structured around having a single fixed View per Activity. Although you can manipulate Views within your Activity's layout, I'd suggest this should be restricted to hiding/showing/moving Views rather than replacing the layout wholesale.
What you probably should consider is the newer Fragments API. This can almost be though of as "activities within activities". A Fragment essentially allows you to wrap up an element of a UI (layout and behaviour) in a reusable component. So in your specific example, the two distinct UIs could be Fragments within a single activity.
This has a couple of benefits such as being able to reuse your UIs in other activities and you can do funky transition animations.
dual activity should work, as you won't be bothered by implementing the back button action.
Activities were made exactly for this purpose. If you prefer, you can have your whole application in a single activity with a custom layout engine (reload components, etc.) and that's what you want to do if you want a "portable" app (e.g. you develop an app with a common UI for various platforms, Andropid, Windows 7, iOS, etc.), but if you want to go Android only, the preferred way is to use the provided APIs, and not to reinvent the wheel. It works fine, and will give users a comforting sense of consistency in their experience (it will look and feel like other Android apps).
The current project I'm working on (a game) already has 10 different activities, and I'm planning more...
Related
as per this answer it is possible to reuse android java code inside web app or desktop app frame.
so how its done step by step?
I wonder if there is a special tool to do so.
I don't think there is a complete tutorial, as it's tedious work. The example you linked shows
Android -> Swing conversion. So I will illustrate this with some examples:
If you have a View in your android app, you replace it with JPanel for swing.
If you have a Button, you replace it with JButton
Sometimes elements may look similar, but they do different things, like CardView and CardPane. This complicates things.
There might be android Views that has no matching pair in swing, so you will have to improvise there
But it's not this simple of course. Setting the properties of the views is going to be completely different. Moreover, Android uses XML, while in Swing you have to set everything programmatically.
The only thing common is basically they are both built on Java. So my best advice is that you shouldn't try to "convert" your code. Maybe you can reuse some pure Java parts, but other than that, I suggest you re write the application using the other platforms tools.
you can't use android code in web app or desktop,
first you have to separate the business code from the ui code
the business code can be in a pure java module (completely reusable)
when i speak about business code i mean network calls (using retrofit for example) and any code that is pure java ..
the ui and android specific code (like Views ...) should be rewritten entirely because will not have access to android packages containing views (recycler, layouts...)
High resolution screens are old news, but for some reason we (and the Eclipse guys) ignored them until now. Well, we can't any longer.
What we want to do is create Eclipse applications that work for "normal" displays, but for high resolution ones, too. Right now the icons are way to small to see or click.
This bug links to this (rather sparse) documentation states we only need to use a new constructor for Image. Okay, so we need to create our own implementation of ImageDataProvider.
While that might work for the images we created ourselves, it does not work for the main tool bar icons.
So let's say we'll start a completely new application from scratch: how would we set up everything to make the toolbar work with the new API and so with all kinds of screens?
(There is a similar question, but it's from the perspective of an Eclipse user, while this question is from the perspective of a developer of an Eclipse application.)
When HiDPI mode scaling is in use anything using ImageDescriptor.createFromURL to load images will look for a image with #2x or #1.5x appended to the name depending on the current scaling (so, for example, remove.png and remove#2x.png). This is used to create an ImageDataProvider.
Eclipse will use this for the tool bar images and many other things.
How are big applications (with lots of windows, lets say users administration, roles, payments, etc) designed. I'm a web developer and I'm used to develop different screens in different html files. I wanna know how to split windows generations in different files instead of having only one huge Application class.
Thanks in advance..
The question is a bit too broad to thoroughly answer, but I still think providing a partial answer here might be useful.
For an implementation of Banislav's strategy of hyperlinks controlling a swappable pane (which does not use FXML), see the related question: How to have menus in java desktop application.
For a small FXML based framework for switching panes see: Loading new fxml in the same scene with associated sample code. Note that sample is for small apps, for large apps a more rigorous framework would be preferred.
The next step up from the small framework listed above would be something like afterburner.fx, which is "a minimalistic (3 classes) JavaFX MVP framework". Even though small, afterburner.fx would probably suffice to be used as the core for a medium sized application. You can find a small sample application built using afterburner.fx named airhacks-control.
For something a bit more involved you can study the source of SceneBuilder and SceneBuilderKit. SceneBuilder is an open source design tool written in JavaFX. Understanding and adapting that code may be challenging for somebody coming from a web background as its implementation differs significantly from a traditional web application.
For very large applications, basing the application on a fully featured platform such as NetBeans RCP would probably be a preferred approach, though, as of this time, that is probably a large and difficult task to do well and likely requires mixing multiple frameworks rather than writing everything purely in JavaFX.
In JavaFX, you can use similar approach as in web development.
Use BorderPane as root pane.
Create main menu
You can use MenuBar with Menus and MenuItems. You can also use TreeView or ListView on like left side of screen. To position TreeView/ListView on left side you could use BorderPane and set it to left with setLeft.
Approach I prefer would be to use HyperLink control. Add multiple HyperLink's to VBox and again, set them on left side of BorderPane. Upon click, they will handle event which set's desired form on center of BorderPane.
I.e.
I'm creating an application on android similar to that of a book. I would simply like to have the scrolling effect between views (not activities) similar to that of the home screen. Currently I am using a ViewFlipper and don't have the animation I would like, since the shift is sudden as opposed to following your finger.
I am aware that there are several opensource projects and classes being developed to achieve such a thing more easily for the individual programmer, but wondered if there was a way I may have overlooked to implement a homescreen-esque effect. An alternative which I have thought of using would be a TabView, with no label tabs being displayed above the content of the page, yet have not heavily looked into this option yet.
If anyone has encountered the same hurdle and has any ideas of how to overcome it, I will buy you a pizza! (Not really... I don't know your address) But I'd be very appreciative! :)
Thanks
I think you're looking for the ViewPager. It's part of the compatibility library.
I am currently toying with the idea of converting a small/medium sized project from AWT to SWT, although Swing is not totally out of the picture yet.
I was thinking about converting the main window to an SWT_AWT bridge object, but I have no idea how the semantics for this work. After that, I plan to update dialog for dialog, but not necessarily within one release. Is this possible?
Has someone done a conversion like this and can give me some hints? Is there maybe even a tutorial somewhere out there? Is there maybe even a tool that can automate parts of this? I have tried googling, but to no avail.
Update: One additional thing is: Currently, this is a netbeans project. Might be of help or not, I don't know.
We have done this quite a few times. But only because we are going from a Swing application to an Eclipse RCP application not because we like messing with things. This project will really let you know whether you've separated your controller/model code from your view code.
One suggestion is to not try and convert everything all at once. You will end up with a bunch of mixed code that doesn't work at all. You can start at converting portals. I would consider a portal anything within a Tab, Dialog, or Window, essentially self contained unit. If you have a window that opens up, create the Window in SWT, but make it's contents the existing AWT/Swing. This should be fairly straight forward and allow you to get used to the (I really hope they weren't drunk and had a good reason for this) way of instantiating and associating parent/child controls.
One gotcha that can occur is with transparent components. Swing, with the exception of a "window" class is all rendered in Java. This makes it very easy to render things the way you want them. In SWT, there are some restrictions:
Borders. If you use SWT.BORDER you are stuck with whatever color the native component uses. Your best bet is to use a PaintListener and render your own borders if you want them in a different style or color.
Transparent labels, progress bars. I have not been able to get Labels or Progress Bars to have a transparent background. If you want them to take on the parent color, or drawing you will need to render the text and other controls yourself.
Controls. There are composites and controls in SWT. Think of Controls as the basic native controls that do all the native API calls. These cannot be subclassed, which makes things difficult.
Tables will give you the most trouble. Make sure everything is stable before you attempt to convert a JTable to a Table or TableViewer. You will spend some time on these, especially if you have custom editors and viewers.
I have not researched why SWT was designed the way it was. I am guessing there HAD to be a good reason. It would be great if someone had a blog or defense to it's design so I don't have to search for it. Once it's posted I'll remove these lines since they have no relevance to the question.
Addition
I want to add that since you have an existing product I assume works. The best piece of advice I can give you is to never let your code get into a state that it cannot compile and run. If you work on your conversion and whatever you check in always runs and executes (despite the visual differences between SWT/AWT/Swing) you will save yourself many headaches in the long run. The worst thing you can do is try to tackle this all at once and get your code in an unstable state for weeks at a time.
I would suggest importing it into a WindowBuilder project, as WindowBuilder gives you the ability to parse existing code and create a GUI mock-up, then morph components to either SWT or Swing.
If you're thinking of using a mix of SWT and Swing in the same application, this Eclipse Corner Article will be immensely useful.
We are preparing the same step: Swing to SWT/JFace. First we try to determine the bottlenecks: reimplement special components derived from JComponent with SWT/JFace, search for a replacement of JIDE docking (we want to use SWT/JFace, not RCP to avoid too much hassle). The worst thing we already imagine is, that in Swing you could create components and adding it later to the parent. With SWT this is not possible: the parent component must be passed as a reference to the child component's constructor. This will require major refactoring in the Swing application before using SWT.
Frankly, we rate the conversion a very heavy change, because we expect the time where nothing can be compiled as quite long. We try to decrease this time by preparing everything as good as possible, but we'll see how good it will work.
Update from April 6th 2011:
We now refactored our Swing application to always create components with their parent (as in SWT). Our subclasses of JFrame and JDialog got refactored to just have a JDialog instance to make it easier to switch to SWT's Shell. In parallel, we rewrite sophisticated components in SWT.