I am building a VR application for VR glasses. Basically, I want to split the screen in two, and have two GLSurfaceViews (one in each side) showing the same in each one of them.
While investigating a bit, I read in some posts that it is not possible to have more than one GLSurfaceViews in one activity (For example: How can I use Multiple GLSurfaceView components in the same Layout?), but I also read (in that same question) that it is indeed possible, so I didn't get a clear picture.
Anyway, I tried to do it by myself. So, in my code, if I just create one instance of GLSurfaceView, everything works fine. However, if I create 2 instances of a GLSurfaceView, I realised that the renderer is created only once (I don't know why).
Thus, since I actually want to draw the same in both surfaces I thought I could just use the same renderer for both surfaceViews. I basically tried to use the first created renderer and use setRenderer() method in the second instance of GLSurfaceView, but this would crash my app.
So, can someone help me to implement two GLSurfaceViews showing the same in the same acitvity (in case this is possible)?
Related
I'm working on an app where I need to draw a lot of data. There are different functions that can be used to work with the data. The main functions share two views, that right now I draw every time I start the functions. They differ in the middle part where the data is displayed different. Right now my main goal is to improve the performance of the app. When I switch from view A to B runs smoother than the other way around. My idea is to store all the parts (from all views) in a list so when I jump back to the view I can reuse them instead of building them again. Is this a good idea? Are there some general performance advices when building an app with javafx?
In GUI desktop development, there is a technique named "double buffering", which is useful to make fast screen flips:
It consists on having two separated and different panels that occupy the whole application viewport and that must be permanently updated, but just one of them must be visible at the same time. Changing from one to another is as fast as to hide one of them and to show the other one.
I was wondering if there was a way to make one component (in this case a JPanel) visible in more than one of the tabs.
I have a simple JFrame which is completely filled with a JTabbedPane. Each tab has a slightly different function, which is why they're in different tabs. However, they each output the same type of information. I was wondering if there was a way to make it so the same output panel could be seen in all the tabs, without having to create one panel for each tab.
I realize that it is impossible to add one component multiple times (and have it display independently each time), which is why I'm not optimistic about this being possible, however if it is, it would make my code much cleaner. In the case that this is not possible, I am completely open to alternate suggestions that achieve a similar result. I am in the very beginning of my project, so it won't be too difficult to change things.
This image gives a rough idea of what I'm trying to make it look like:
I have searched around for anyone dealing with this issue, however I have had little luck finding anything relevant. If I missed something, I apologize for wasting your time.
I have an application that is a Maths Game for kids. Since I'm in college, I've usually only had a god object for all my past projects but for this applciation I've split my code into multiple classes:
MathsGame.java: main class which initialises components and constructs and controls the UI.
DiffScreen.java: contains methods for use on the difficulty selection screen.
GameScreen.java: contains methods for use on the game screen.
EndGameScreen.java: contains methods for use on the end game screen.
MigJPanel.java: extends JPanel and sets layout to MigLayout and adds a matte border.
Each screen that the 3 XScreen classes control is simply an instance of MigJPanel and screens are switched to using a CardPanel container JPanel.
I'm wondering how I can divide my code to each class so that they are properly abstracted but I'm not entirely sure how to approach this.
Should my 3 screen classes be extending from my MigJPanel so these then can be instantiated?
So instead of having my DiffScreen, GameScreen, and EndGameScreen classes solely containing methods related to each screen which are then called from MathsGame, each screen will control itself within its own class.
If yes to the previous question, should the UI components for each screen be made inside that screen's class?
At the moment, all components for each of the three screens are created in my MathsGame constructor. This makes the connection between a screen and the class which 'controls' (I use this word very lightly at the moment) it even further apart. So each screen is just an instance of MigJPanel whose components are constructed in MathsGame. The only relation the EndGameScreen class—for example—has to the End Game screen is that when the MathsGame causes the End Game Screen to be displayed, anything done there makes a method in EndGameScreen be called from MathsGame.
I hope I explained myself well. If not, leave a comment and I'll clarify. Any help would be greatly appreciated!
Yes
Yes.
Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirectly (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed, for example.
You could also use interfaces to maintain common functionality if required, so if the MathsGame really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the MathsGame only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion..
Also, where should I put the code for switching between screens?
From my perspective, it's the responsibility of the MathsGame game to determine when and to which screen should be shown. What I would normally do, is provide some kind of notification process that the current screen can ask the MathsGame to switch screens, maybe via a listener or other agreeded interface. This would mean that each screen would need reference to MathsGame.
Instead of passing it (MathsGame) directly, I'd create an interface that MathsGame would implement (say NavigationController), which defined the calls/contract that each sub screen could use (nextScreen/previousScreen) for example.
Take a look at Model-View-Controller for more ideas
I would like to create a custom Android button from 9patches, but without using any XML. I know, it sounds dumb, but the reason is that for some reason my IDE (NetBeans) messes up the whole XML beyond belief. The R.java doesn't get generated half the time (the fixes didn't work for me), and I get random errors, even if I just copy and paste XML from tutorials.
This is how I plan to create the Button:
The button has a setBackgroundDrawable() method
I need to suply this method with a StateListDrawable
Which I need to build up from NinePatchDrawables
So first I need to create the 9patches, then a StateListDrawable from them, and simply pass the StateListDrawable as background for my Button's setBackgroundDrawable() method.
I can't start the 9patches, because I can't find out how the constructors work.
Wouldn't it make more sense for you to invest your time in either:
fixing NetBeans, or
switching to some different editor/IDE?
Trying to do Android development without XML is akin to trying to fly without wings. It's possible, but rockets tend to crash and burn in the end.
Regardless, you do not need to directly work with NinePatchDrawable to use nine-patch PNG files. Android will handle that part for you.
Instead, create an instance of StateListDrawable and call addState() for each one of your states. To get the Drawable for the state, use getResources().getDrawable(R.drawable.this_is_one_of_your_nine_patch_images) from your Activity. Android will detect that this is a nine-patch and will do the right thing.
I swear, this control has been the bane of my existance this week. Just FYI, I have pretty basic OO/Java skills, I've mainly been using xml to create layouts, but I need to use the gallery control. I've finally got the sample code working from the sdk, but one thing remains a mystery despite looking here, googling elsewhere, etc., there seems to be no clear answer on how you exactly manipulate the attributes of individual images within the gallery. I keep looking for an example of a template that I could implement, but see nothing. Really, I'm not looking for anything fancy, I just want the images to scale properly within a fixed height gallery control, and surround each image with a 1dip light border, and keep each of them about 4dip apart from one another, that's about it. But for the life of me I'm just not seeing how to make these customizations, and I'm starting to tear my hair out! :-/ Any help or reference to how to do this with some actual examples would be priceless!
Yeah, just to continue on your own answer.
The getView() method of the adapter is the place where you'll do anything you want with the images, i.e. set up borders, layout params, lazy loading, etc.
As long as the method returns the View you've made changes to, it should work just fine.