I've been trying for a while to get some JUnit tests to work in a project using the Maven version of Libgdx, but did not manage to succeed.
In my project I have a class that handles the audio for my game. For now the class is quite simple, and does not do much more than looking for an audio file in a folder, and playing it. I use the Gdx.app.internal() to get the file that I need, and it workd perfectly fine when running the game.
Now when I write a test file, which is in the root/core/target/test-classes/.... folder, the Gdx.app.internal() immediately throws an exception. When using FileHandle.exists(), it returns true when running from the game, but false when I run it from tests.
My guess is that it might have to do with some dependencies that Libgdx needs, and when running the game normally all is set for you. Thus I tried looking up some other topics that discuss this, but did not manage to find much information about it.
So to summarize my question: Is it allowed to call for Gdx.files.internal() in a JUnit test case? If not, what is the best way to go about testing classes in your Libgdx project?
Related
On that video: Coding with Notch we can see how Notch makes changes to Minecraft code and can immediately see the changes in game. I think that is very efficient and I would like to know how he does that!
Three Things
He is using the same workstation, He is just extending his screen.
Debug mode in Eclipse with breakpoints in those functions that are
most likely to be called in every actions in the game.
Eclipse emulators to run jar files. Similar to apk emulators
I'm developing my own game without any frameworks and engines (except JBox2D cause I have very big troubles w/ physics). I need to load .tmx file into my game. The only ready-to-use option was LibGDX with his TmxMapLoader. I added dependency to project, ran and got quite expected crash:
Attempt to invoke interface method 'com.badlogic.gdx.files.FileHandle com.badlogic.gdx.Files.internal(java.lang.String)' on a null object reference at com.badlogic.gdx.assets.loaders.resolvers.InternalFileHandleResolver.resolve(InternalFileHandleResolver.java:26)
What I supposed to do to load .tmx from assets using TmxMapLoader?
Probably the best solution would be porting game to LibGDX but I have no time and desire to study documentation and rework that I already have.
If you don't want to use LibGDX framework and its file module, I'd suggest simply going through TMX-related code and convert it the way you want it. LibGDX is open-sourced, after all. FileHandle is just a wrapper over File on most platforms, it should be straightforward to replace (or include in your project and used with File constructor). Java provides its own XML readers, so if it comes to that, you'll be able to replace any XML-related LibGDX code as well.
I'm afraid the default loader implementation loads textures as well, so without running an actual LibGDX application, it will not work. However, if you don't mind including LibGDX jars, you could try extending this class and removing all texture-related code or replacing it with your custom image-loading code.
How can I make it so Eclipse automatically updates my code in a window as I edit it? I've seen the feature before in youtube videos but I cannot find it. For example : I change a JApplet rectangle width from 20 to 10, I want to see it update immediately.
I've seen Notch do this on development videos (Minecraft), it is awesome but I don't know exactly how he does it.
-- EDIT --
This has been bugging me so I went and googled "how does notch code" and found this on a blog page https://gun.io/blog/what-i-learned-from-watching-notch-code/. It doesn't say exactly how it was done but gives a good hint (HotSwap) and makes it seem like he set it up himself without external software. Here's the most relevant section:
Incredibly Fast Testing
He began by building the engine, and to do this he used the ‘HotSwap’ functionality of the Java JVM 1.4.2, which continuously updates the running code when it detects that a class has changed.
When building the engine, Notch wrote a function which would continuously pan the camera around and clip through the walls and keep the view on top, so he could make changes to the code and see the effects they made in real time. I’m used to testing by writing a function, building it, installing it on the device I’m testing on, and then seeing the result, which can take up to a minute at a time, so it’s easy to see how HotSwapping could save a lot of development time.
--- ORIGINAL POST CONTINUED ---
I get a similar effect by using groovysh though, works smoothly and can use all your java classes as is.
What I'll usually do is write all my code in java, then go and fire up "Groovysh" where it will give you a little window to enter commands (You may have to ensure the classpath works correctly outside of eclipse). I can then "new" any of my classes and call methods on them one line at a time. When you do myFrame.setSize([100,100]) you will see it change immediately.
A good test is to just run groovysh and type something like:
import javax.swing.*
f=new JFrame()
f.setVisible(true)
f.setSize(100,100)
or the groovier version:
f=new JFrame(visible:true, size:[100,100])
and you will see your frame resize on the screen. You can even drag it bigger and then do something like:
println f.getWidth()
to show your new width. It's fun to interact this way but it's more complicated if you want to actually change your class definition and see it pick up the change, I have no idea how Notch did that. I looked into it a little--it's possible he was using something like JRebel
It requires something special since you would have to dynamically reload the classfile into your running system on every save--something that should have serious classloader issues.
By the way there is also a way to get your Java program to throw out a little GroovyConsole which will allow you to inspect and modify all the variables in your running code (but again you can't replace definitions of existing classes).
Also see answer here:
Change a method at runtime via a hot swap mechanism
I recently started learning about Android app development. It's also my first experience with the Java language.
There are some debugging tools that I want to incorporate into my app development in a form of Java package dependency. For obvious reasons, I would like to include it only for debug builds.
In iOS, we can use build configuration to link with debugging libraries only for debug builds, and use macros to remove parts of code that deals with debugging. This makes it really easy to switch between debug and production builds. Anyway to achieve the same for Android?
So far, the closest I got is using Maven profiles to overwrite properties files, which gets loaded by the application, but this requires that the debugging libraries are still imported.
To clarify my question, here is what I want to do:
I built a library that will let you browse the SQLite database on your browser. It's really useful for debugging purposes, but I don't want to ship my app with the library.
Another purpose is to use HockeyApp. HockeyApp provides two features: Update notification, and crash reporting. I need three different builds for this to work:
Production: Crash reporting On, Update notification Off
Beta: Both On
Debug: Both Off
In the manifest's <application>, you can set the debuggable attribute. Eclipse does this for you automatically if you omit the attribute. Debug builds have debuggable=true, well exported builds have debuggable=false.
This affects Log.d, and you can conditionally check in code using the following:
boolean isDebuggable = (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE));
In addition to Maven, one way is to use a dependency injector like Dagger
By building on standard javax.inject annotations (JSR-330), each class is easy to test. You don't need a bunch of boilerplate just to swap the RpcCreditCardService out for a FakeCreditCardService.
Dependency injection isn't just for testing. It also makes it easy to create reusable, interchangeable modules. You can share the same AuthenticationModule across all of your apps. And you can run DevLoggingModule during development and ProdLoggingModule in production to get the right behavior in each situation.
One way to solve this is to check the return value of PackageManager#getInstallerPackageName. It returns null if the apk was installed manually through adb, through a web page, or through a service like HockeyApp. In fact, I recently added a similar check to our sdk, see this commit.
Note that this solution is only reliable if you only distribute your (paid) app though Google Play. Last time I checked, alternative stores like the Amazon App Store or AndroidPIT were not setting the installer source (it is possible to set it since API level 11, see PackageManager#setInstallerPackageName).
Another option is to check the package name at runtime. For your beta builds, you would append ".beta" to the package name and then check for this suffix to enable in-app updates or debug stuff. You can do this by moving your code base into a library project and set up two app projects that reference this library project: one for the store app, one for the beta app. Our use aapt with the option --rename-manifest-package to change the package name of beta builds (see details here).
do you have use BuildConfig.DEBUG, this is created by android adt tool
/gen/BuildConfig
I would like to create a java app that actually programaticlly compiles a differnt android project - Meaning i'd like to create .apk files by code. How would i go about this??? Is this feasible?
Thanks
Sure, it could be done. If there is a way to build an Android project by command line, you can make those calls with Java I'm sure. See this and this link for information on building Android programs from the command line. From there, its simply invoking the correct commands in Java, maybe using Runtime.exec().
This will require a good understanding of the build process, and will most likely get very cumbersome. So an answer to your question as to whether or not it is feasible: no, it would be difficult.
You could use Ant to automate your build process.