I'm trying to have several gamepad at the same time in JInput, while also checking for newly plugged gamepad. Here is the code used to check for new controllers.
new DirectAndRawInputEnvironmentPlugin().getControllers();
If I run this code several time and store the results, the same peripheric appear on a different "Controller" instance amongst the results. Which lead to a lot of problems.
How do I check if two instance of Controller are similar ? IE if they control the same peripheric ?
I guess it could work if I checked for the name/number of components/rumblers, etc to see if they are similar (like hashing the device). But what if I plug the same gamepad twice ?
Thanks !
Currently you can't do this with JInput. Ideally you would be using the DefaultEnvironmentPlugin too, which will auto detect for the platform you are running on.
There is an interface in JInput for controller connection/disconnection, but it's never been implemented. I've asked a number of times for volunteers, but nobody seems to worry about it enough to do it. Feel free to contact us over on the javagaming.org forum if you wish to implement the notification interface.
Related
I know enums are used when we are expecting only a set of values to be passed. We don't want the caller to pass anything other than the well defined set.
And this works very well inside a project. Because you know what you've to pass.
But consider 2 projects, I am using the models of 1st project in 2nd.
Second project has a method like this.
public void updateRefundMode(RefundMode refundMode)
enum RefundMode("CASH","CARD","GIFT_VOUCHER")
Now, I realise RefundMode can be PHONEPE also, So If I start passing this to 1st project, it would fail at their end (Unable to desirialize enum PHONEPE). Although I've added this enum at my end.
Which is fine, because If my first project doesn't know about the "PHONEPE", then it doesn't know how to handle it, so he has to update the models too.
But my problem is, Let's imagine a complex Object am trying to pass, which also takes this RefundMode, when I pass a new RefundMode just this field should be become null or ignored at their end right ? Rather than not accepting the whole object, and breaking the entire flow/request.
Is there a way I can specify jackson (jsonproperties) to just ignore that field if an unknown value is being passed. Curious to know.. (Although In that case, I am breaking the rule of ENUM) So, why not keep a String which solves all the problem ?
It's all about contracts.
When you are in a client/server situation, being a mobile app and a web server, or a Java library (jar) and another Java project, you have to keep the contracts in mind.
As you observed, a change in contracts need to be propagated to both parties: the client and the server (supplier).
One way of working with this is to use versioning. You may say: "Version 1: those are the refund modes.". Then the mobile app may call the web server by specifying the contract version in the URL: /api/v1/refund?mode=CASH
When the contract needs to be changed, you need to consider what to do with the clients. In the case of mobile apps, the users might not have updated their app to the latest version, so their app may still be calling /api/v1 (and not supporting new refund modes). In that case, you may want to support both /api/v1 and /api/v2 (with the new refund mode) in your web server.
As your example shows, it is not always possible to transparently adapt one contract version to another (in your example, there is no good equivalent to PHONEPE in the original enum). If you have to deal with contract updates, I suggest explicitly writing code to them (you can use dedicated JSON schemas, classes and services) instead of trying to bridge the gaps. Think of what would happen with a third, fourth version.
Edit: to answer your last question, you can ignore unknown fields in JSON by following this answer (with the caveats explained above): https://stackoverflow.com/a/59307683/2223027
Edit 2: in general, using Enums is a form of strong typing. Sure, you could use Strings, or even bits, but then it would be easier to make mistakes, like using GiftVoucher instead of GIFT_VOUCHER.
I have an app that has a lot of data that I need between the pages, such as:
design settings, user parameters, scanner access, printer queue, multiple things that got calculated and formed on one page and will be used on the others.
The general idea of the app is: you quickly select options or input data on each page and then it forms an order, sends it and prints it.
I have several repositories for different things but I can't get how to give access to them from the destination-fragments.
I'm pretty new to Android so I'm trying to find the best way to build this system but failing to do so.
What I found so far:
Room - I don't think so. I honestly tried it for several weeks but loading and saving data is unbearably slow especially when it's just a bunch of menu-pages flipping one after another. Also, I don't need to save data locally between the sessions, so it kind of misses the point of the local database.
Send some simple strings/numbers between the fragments - serialization/deserialization of everything I need for each menu doesn't sound great.
ViewModel factory - this way you need to create and store the ViewFactory somewhere and then access it from each fragment and then build a new ViewModel with it. Kind of might work but looks weird. How should it work? We have a link to the Factory in the "main" ViewModel and then get a link to this "main" app's VM, read the factory and then init local fragment's VM?
One big application's ViewModel - doesn't sound right: too big, too bulky.
Singleton(s) - that's just sad.
Dependency injection - I didn't try Dagger yet (going to, right now). Is it the thing I'm looking for?
I tried to google a lot on this topic but all of the answers look like: "here's how to pass a simple string between the screens", how do people organize the more complex applications? Maybe there's a more sophisticated way to split the application state into some kind of services or other terms that I'm missing.
Could you please help me to understand the proper application architecture in terms of state and data?
I think that your solution is something between a session implementation (in memory or using Room) and a ViewModel for the parts where a screen depends on another. If it is a flow I recommend you to use a way to share the ViewModel between the fragments like this or this (which I use and recommend) and then setting it as a state for the rest of the flow, leading to shared data that survives some config changes. If you need the settings surviving throughout the app execution you should implement a session using a simple class singleton or a Room implementation.
Consider this line of jsp code:
function clearCart(){
cartForm.action="cart_clear?method=clear";
cartForm.submit();
}
Clearly it's trying to call a method on the back end to clear the cart. My question is how does the service (Tomcat most likely, correct me if I'm wrong) which hosts this site that contains this snippet of code know how and where to find this method, how it "indexes" it with string values etc. In my java file, the clear method is defined as:
public String clear( )
{
this.request = ServletActionContext.getRequest();
this.session = this.request.getSession();
logger.info("Cart is clearing...");
Cart cart = ( Cart ) this.session.getAttribute(Constants.SESSION_CART );
cart.clear();
for( Long id : cart.getCartItems().keySet() )
{
Item it = cart.getCartItems().get(id);
System.out.println( it.getProduct().getName() + " " + it.getNumber()
);
}
return "cart";
}
By which module/what mechanism does Tomcat know how to locate precisely that method? By copycatting online tutorials and textbooks I know how to write these codes, but I want to get a bit closer to the bottom of it all, or at least something very basic.
Here's my educated (or not so much) guess: Since I'm basing my entire project on struts, hibernate and spring, I've inadvertently/invariably configured the build path and dependencies in such ways that when I hit the "compile" button, all the "associating" and "navigating" are done by these framework, in other words, as long as I correctly configured the project and got spring etc. "involved" (sorry I can't think of that technical jargon that's on the tip of my tongue), and as long as I inherit a class or implement an interface, when compiling, the compiler will expose these java methods to the jsp script - it's part the work done by compiler, part the work done by the people who composed spring framework. Or, using a really bad analogy, consider a C++ project whereby you use a 3rd party library which came in compiled binary form, all you have to do is to do the right inclusion (.h/.hpp file) and call the right function and you'll get the function during run time when calling those functions - note that this really is a really bad analogy.
Is that how it is done or am I overthinking it? For example it's all handled by Tomcat?
Sorry for all the verbosity. Things get lengthy when you need to express slightly more complicated and nuanced ideas. Also - please go deep and go low-level don't go too deep, by that I mean you are free to lecture on how hibernate and spring etc. work, how its code is being run on a server, but try not to touch the java virtue machine, byte code and C++ pointers etc. unless of course, it is helpful.
Thanks in advance!
Tomcat doesn't do much except obey the Servlet specification. Spring tells Tomcat that all requests to http://myserver.com/ should be directed to Spring's DispatcherServlet, which is the main entry point.
Then it's up to Spring to further direct those requests to the code that handles them. There are different strategies for mapping a specific URL to the code that handles the request, but it's not set in stone and you could easily create your own strategy that would allow you to use whatever kind of URLs you want. For a simple (and stupid) example you could have http://myserver.com/1 that would execute the first method in a single massive handler class, http://myserver.com/2 would execute the second, etc.
The example is with Spring, but it's the same general idea with other frameworks. You have a mapper that maps an URL to the handler code.
These days it's all hidden under layers of abstraction so you don't have to care about the specifics of the mapping and can develop quickly and concentrate on the business code.
I try to explain my problem as short as possible:
I got an AgentTypeOnly called customer, the data of the customer is in a database. I dont wan't to create all my agents at the beginning of the simulation. They should appear after a defined time, then they have to do a task and after the task is finished they have to dissapear (sink). At the moment i am creating them with a source block, but i am quite sure, that there is a better way to do it. For example a code in the main.
Thanks for the help, I hope u get my question
depending on the modeling technique you use, you can do it in different ways. When you use agent type only, you can only create agents using the source from the process modeling library.
If you use agent-based then instead of agent-type you have to use a population initially empty. then, for example if your agent population is called customers, you can create an agent whenever you want using the code add_customers();
None of these techniques is better than the other and it depends on your application
Introduction
I’m attempting to switch my application from windowed to fullscreen. Earlier this would have been as easy as making use of LibGDX’s setDisplayMode(Display), as well as the same library’s getDesktopDisplayMode(). Unfortunately, some things have changed.
Research
As of LibGDX 1.8.0—inside the Graphics—what was previously known as setDisplayMode(DisplayMode) has been renamed to setFullScreenMode(DisplayMode), as well as what was previously known as getDesktopDisplayMode() has been renamed to getDisplayMode().
By then, one might think, that using the renamed methods in the same way as one previously would to switch from windowed to fullscreen would work just as fine:
// Tabulator key triggers change from windowed to fullscreen
// The application works fine until that of pressing the tabulator key
if(Gdx.input.isKeyJustPressed(Keys.TAB))
Gdx.graphics.setFullscreenMode(Gdx.graphics.getDisplayMode());
This doesn’t work fine by any means. As a matter of fact, the application hangs followed by crashing upon pressing the tabulator key.
It’s worth to notice that the setFullscreenMode(Display)—according to the documentation—returns a boolean depending on whether or not the operation was successful. In this case, if you were to put it inside a print statement, you can clearly tell it never returns: even should you let the application be for a while.
Moreover
I took a good look around the web—in vain—searching for possible causes of as to why this might be happening. Looking at the release notes of 1.8.0, it truly seems as though all that needs be done is switch from using the previous methods contained by the library to the new ones.
Question
Does anyone have any insight on as to why the application crashes upon pressing the tabulator key—granted the code following it as shown above is present? Perhas someone could at the very least point me in the right direction?
There’s a fair chance what I’ve concluded is missing out on some important facts.
Solution
It turns out I’ve managed to be slightly silly!
Background
Whenever I create applications—especially games—even though I use libraries such as LibGDX, I like to go ahead and create myself a separate thread for handling the game logic. This yields me more control over the application as a whole—whether it be tick extremely frequently whilst rendering more seldom, or the other way around.
By the way of my logic, the provided code from the question...
if(Gdx.input.isKeyJustPressed(Keys.TAB))
Gdx.graphics.setFullscreenMode(Gdx.graphics.getDisplayMode());
... I decided to put inside the tick method. Since that’s inside a separate thread, LibGDX probably felt a little left out.
Moreover
From my understanding, LibGDX handles all its logic inside the ApplicationAdapter’s render method. That’s where it evaluates all of the user’s actions and makes sure they don’t collide with other things taking place to its own various different components.
For the aforementioned reasons—when I decided to put the “fullscreen logic” inside a separate thread, LibGDX crashed. Oh well, at least it works now—That is, by putting the aforementioned code inside the LibGDX’s ApplicationHandler’s render method!