07
May
20

Version 2.0 (And 2.01) released for Android

Last summer, Google dropped the support for Google Cloud Messaging and now demanded only the usage of Firebase Cloud Messaging to send and receive notifications to an app.

Now, one could think that it just would be a matter of implementing Firebase then? Well, unfortunately RummyFight-Android was created using Eclipse and Firebase can only be implemented using Android Studio which meant I had to migrate the whole project to Android Studio.

Of course the automatic migration would not work since it’s such a complex project so the only way for me to succeed was to create a blank project in Android Studio and import piece by piece into it, adjusting every part of the source and resources to work in this new environment.

If that wasn’t enough, I had to do something about my usage of AndEngine. It’s a 2D graphics library that I had always used for all the dragging, dropping, updating of the interface etc. In the old RummyFight I used AndEngine GLES1 (For OpenGL 1.0) and of course that doesn’t work in Android Studio. However there exists a GLES2 version (For OpenGL 2.0) that could be hacked into working so I tried that and actually succeeded.

A lot of things had changed in the GLES2 version though so I needed to go though all code and redesign a lot and also re-invent the wheel some since a few functions was removed. That is the reason for the Fireworks looking different in v2.0. The particle system had changed a lot since GLES1 so I had to create a completely new fireworks solution.

I also had to change a lot regarding the fetching of profile pics and theme backgrounds to make them work in GLES2.

But eventually the app finally compiled and I could start testing it… realizing there were yet a lot of things to fix.

One of them was the popup of dialogs. GLES1 ran on uiThread but GLES2 on backgroundThread meaning that if someone clicks on a player name, the app would crash when opening the profile dialog since it MUST be opened on the uiThread.

So I had to find all places where i open a dialog and surround the code with

runOnUiThread(new Runnable() {
    public void run() {
        OpenTheDamnDialogHere();
    }
});

What I then believed was the last step to do was to make the app accepted by Google Play which meant creating new, larger icons it it to take into account that newer phones and tablets with higher resolutions have been released the last 4 years. That included app icons, notification icons etc. Apparently app icons should be round now, not square… but still needs to be square if the app is installed on an older device.

Notification icons I said? Hmmm… Oh, new rules from Google. They must be black and white only now if you use a modern device. Ok, draw a new one black&white then and include code to distinguish what Android version are used and select the appropriate icon.

And while on the topic of notifications: Firebase supports two types of messages: Notifications and data. However if I send a notification message to RummyFight while it’s in the background, the receiving device will only play the standard notification sound. Since there is an option in RF-Settings to select your own sound I wanted that function to be kept which meant that Data-Message what the way to go and give all the logic to the app instead of the system.

Then, of course I had to change in the server how these messages were sent to the devices but at last I got it working.

Ok, back to releasing it to Google Play.
Create APK, upload it, all looks good… then a BIG WARNING:
“The app uses READ_PHONE_STATE – This is not recommended”

What? It does not!!!

Actually it was a bug in Android that added this permission by itself but I found a solution that worked. I added READ_PHONE_STATE in the code and then immediately removed it efterwards, hehehe 🙂

New upload – rejected since not all parts of the app was 64 bit code. What??? I thought all java would compile into 32 and 64 bit automatically? Yes, but there were parts of andEngine that was only 32 bit. Luckily some nice people on the net had managed to create 64 bit libraries of andEngine that I could import and finally the app was accepted by Google.

They informed me a release could take up to 7 days to be accepted so I started working on other things but already after 18 hours the new version was live… and it crashed hard!

After some debugging and looking at crash reports I realized that this only happened on Android 9 and 10. Seems that the http object used in the app to fetch info from the servers is totally ok to use up until Android 8. From 9 and forward another object must be used… or at least explicit support for the old version must be stated.

I stated!
<uses-library android:name=”org.apache.http.legacy” android:required=”false”/>
and also added a policy saying that http requests to *.rummyfight.se is allowed, not only https.

Then I submitted v2.01 and keeping my thumbs really hard it will work this time.

Damn it’s difficult to maintain a 8 year old project where the latest release was done 4 years ago.

30
Nov
17

So, what’s next?

Now when v1.60 for iOS is released and seems to be working fairly well, it’s time to think about what to do next.

  1. I will very soon release v1.61 of RummyFight for iOS. There are some small bugs in the app I want to take care of as soon as possible. Nothing major but still a bit annoying maybe. One example is that all dialog windows (like the chat etc) look quite small on iPads. This is because they are not scaling the same way as the game itself does. I have already starting the work on this.
  2. It’s time to create a new update for the Android version too. The reason I haven’t done that in a year is that Google has dropped their support for Eclipse as the main developer’s suite and wants all developers to use Android Studio instead. RummyFight has always been an Eclipse project and it’s quite tricky to migrate existing projects to Android Studio which has left me with a perfectly fine project impossible to compile and submit to Google since about a year. I have however begun the migration to Android Studio and as soon as I’m done with that I can start working with the code again.

So, that’s just about what I can say right now. Feel free to comment on this post with suggestions that could improve RummyFight. New ideas are always welcome.

28
Nov
17

v1.60 for iOS now released

So, now that v1.60 finally is released I thought I could summarize what’s new or changed in it

IN GENERAL
To be able to create a version of RummyFight that works on iOS11, I needed to update the developer suite called XCode. For that to even install I needed to update the Mac OS. The problem was though that my Mac was too old for that so I had to get a new Mac first. Then I installed the newest OS, downloaded XCode, opened the project and thought this would be easy.

But noooo.

The old version of RummyFight did it’s own memory management. It allocated and deallocated data itself without any help from iOS. The problem was that Apple now has decided that all apps should use the built in ARC instead (Automatic Reference Counting) which deallocates data when it’s not needed anymore. Normally this works just fine but sometimes it guesses wrong which turned out to be a big debug problem for me.

Anyway, sure. I removed all deallocations in my code and changed the structure some… but still RummyFight was using an external 2D graphics engine called Cocos2D and that one did also it’s own deallocations. Cocos2D is huge and I don’t know my way around all it’s code so I instead chose to update it to version 3, which supported ARC. Fun thing though: Cocos2D v3 was very different from v2 so I had to rewrite almost all usage of that engine. Sometimes small changes, like that the color white was called 255,255,255 in the old version and 1.0, 1.0, 1.0 in the new one. Not difficult but cumbersome. I mean, the source code of RummyFight is more than 30.000 lines now. Lots to look through

But some changes were bigger, like how to use Actions callbacks, using animated sprites, adding textures from pictures etc. So this was a BIG challenge for me and it took a lot of time. The majority of the 1.5 years that this update has taken has had to do with the conversion to Cocos2d v3.

Anyway… next obstacle.
When the old version of RummyFight was created, only iPhone 3 and 4 existed (and the iPad of course). Since the app was an iPhone app (not a universal), it did however work on the iPad too even though it was scaled and didn’t really look good. Now, the new version has to deal with iPhone 5, 6, 8, X and multiple types of iPads. All with different resolutions, screen sizes, aspect ratios etc.

So I needed to find a solution to that too. What would I do with the extra space on wide screens. How should I handle the extreme resolutions now available in the new phones, etc. How would it affect the positioning av things in the app if the screen was three times larger than the app originally was built for. Would a button placed at coordinate 320,160 still be in the middle of the screen or down to the lower left now?

Well, it turned out it was the lower left so EVERY coordinate in the app had to be changed from absolute to relative. Like, “Place this button 10% to the left of the middle of the screen” etc.

But finally I found out a way to do it and piece by piece all screens started to look close to the old ones.

dump_lobby_ipad
Here’s a screen capture from an iPad. You can see that I’ve added black borders to the top and bottom for that kind of screen size.

dump_lobby
Here is the same screen from an iPhone 8 where you can see I’ve added graded green space to the left and right.

SO OK. GIVE ME THE RUN DOWN ON ALL NEWS AND CHANGES
Ok, we start with the Lobby above. Nothing much there is changed. However a few small bugs are fixed though and also some translation fixes of words too long to fit. Visually it looks more or less the same apart from the Footer which now looks the same on all screens (it didn’t before). The Top on all pages are now also animated and the buttons are not completely static anymore. I thought it would bring some life into the app again.

dump_greengameSo, what’s changed inside the Fights then? Well, as you can see the player in turn is now a big yellow panel instead of just yellow text. Also, clicking on the stack of tiles in the upper right corner now opens a window with detailed fight history: When someone made a meld, how many tiles it used, when an opponent did a NewTile etc.

Also fixed a bug which has been around since RummyFight v1.0: When placing bad tiles on the board only the last placed tile were flashing, showing it is bad. Now all bad tiles flash.

Oh yeah, you might notice the clock in the upper right corner? It shows how many hours, minutes and seconds you have left before you are timed out. Great for Speedgames.

Also updated and changed a few of the Gifts, including a new version of the Hoarder song. A nice little addition too is that you now can cancel the download of a theme by tapping on the download dialog window. Pretty handy if you are on a slow connection or something.

dump_tetpuzTetpuz has gotten a makeover with new tile graphics. I’ve also added the MINE-section in the highscores (showing YOUR best scores) and also how many submitted scores there are.

I’ve also added a visual explosion animation when blowing up a bomb and tweaked the numbers a little to make the debris move better. And yeah, almost forgot: Try to tilt your device while having debris at the bottom of the screen. I’ve always wanted to add that feature 😉

IN THE END
Of course there are multiple other things changed in the app too but these are the ones I can remember straight from the top of my head.

I would say that 80% of my work has been invested in just making the code compile again. Then 10% has been about debugging and sorting out issues related to the ARC (memory management – objects disappeared before the app was done with them etc). The last 10% is related to the new features and making them work.

Add almost three whole days of work including a long phone call to tech support in USA just to be able to upload the app to Apple for review and acceptance. It’s almost ridiculous how difficult it is to release apps to them. You really need to be a rocket scientist for that.

SO WHAT’S NEXT?
Well, let’s wait a little and see how well this v1.60 works in reality before making any new plans. I mean, surely there will be a need to fix some urgent new bugs. And then we have christmas. I have 2 kids, a wife, three cats, a horse, 50 fish, 2 axolotl lizards, a job and a life. Give me a time to breathe and we will see what 2018 will bring to RummyFight.

More than 30.000 lines of code now! How about that

 

23
Nov
17

Now we are CLOSE

Been working like a maniac the last week with the new “RummyFight for iOS8 and above” and as far as I can see in my papers I have now only ONE bug left to fix before it’s possible to release it.

When I woke up this morning there were TWO bugs left but I have finally made the notifications to work in the new version too, without having to change anything in the servers.

So, why did it take so long and what’s left then?

Well, the thing is. When I originally developed RummyFight there was the iPhone3 and iPhone4 only. The main difference (for me) between them were just that the iPhone4 had twice the resolution, meaning that I had to include two versions of all graphics and also recalculate everything’s positions according to the detected screen size.

Then… the iPad came, then the iPhone 5 (with a different screen ratio), then iPads with retina resolution, larger iPads, larger phones etc etc.

So, what I needed to do was build a coordinate system and layout capable of handling all these different screen modes.

And I think I’ve made it.

The new version of RummyFight will still work on iPhone 4 and then it will look like this:
iPhone4
Pretty similar to the old verison, right?

Then there’s the iPhone 5, 6, 7, 8 etc which uses a wider screen:
iPhone8s
Looks almost the same but there are some shaded borders to the left and right.

And finally, the iPads which have a very different screen ratio. This is what it will look like on them:
iPad2
This is a mix between the iPhone4 and iPhone5 modes but with black borders at the top and bottom.

So, the last thing to fix is that the coordinate system doesn’t quite work for iPads in the NEWFIGHT section. The players dragged to the seats have an offset I need to fix.

But otherwise, it seems to work elsewhere.
So, fix this in the coming day or so… breathe for an hour or two.

And then release!

/Totta

05
Nov
17

Well, how about that?

Skärmavbild 2017-11-05 kl. 14.47.44

Still quite a few bugs to fix before it’s worth releasing but it actually works now. I can even play and make melds with it. However, as I said, there are still bugs left that I need to fix, like Theme Pictures being positioned on top of everything else and in the wrong sizes, accessing the camera from SETTINGS makes the app crash and several other things.

But it does work.
Nobody is more surprised than me.

16
Oct
17

Making progress

I’m finally making some progress again with the new iOS version that should work with iOS 11. There are SOOO many things that need to be changed in the source code and some parts that have to be completely rewritten.

Due to the size of the RummyFight source code it is very difficult to know exactly what to rewrite and how, just to test if it’s working so instead of wasting a lot of time on this I have instead started programming a completely different app.

Why you ask?

Well, that app is using a lot of the same things as RummyFight. It can access pictures in the camera roll, it can open the camera, it can render bitmaps on the screen and allow them to be moved etc.

So while creating this new app, I’m also learning how to do things “the new way” and as soon as I have figured something out, I switch to the RummyFight project and implement working changes there.

So, now RummyFight can once again access the camera roll, open the camera, download theme pics and render them in the correct sizes etc.

Next task is to solve some memory issues that makes the app crash very often since the ARC is deallocating objects before I’m done with them.

Hope to find a strategy for this soon.
Keep your fingers crossed.

17
Sep
17

Sorry for being quiet lately

I hope to resume with working on the new RummyFight version for iOS very soon. I’m sorry I haven’t done much lately but here’s the reason why. I hope you can understand 😉

LM1A5627-1-1030x687Me on the right, My now wife Susanna (“Messer” on RummyFight) to the left

17
May
17

Impossible mission

As some of you have noticed, RummyFight will not work on iOS 11 and is in need of an update. However it’s a VERY long time ago since the iOS-version of RummyFight received an update… and there’s a reason for that. Or rather, LOTS of reasons.

But to summarize: The code for iOS-rummyfight was originally written in Objective-C in XCode 4.3 and it used Cocos2D v1.1 for it’s graphics. Now, back in those days there were no automatic memory management so all allocations and deallocations were made manually by me in the code. Then time went by and one day I received a mail from Apple stating that they had released XCode 5. Sure… not problem. I didn’t care really. I mean, I could still compile RummyFight with v4.3, right?

Then there was a release of XCode 6, XCode 7, XCode 8… and at some point Apple also announced that they no longer would accept apps built with older versions of XCode.

Fine, I thought. It’s probably a sane decision by Apple, and how hard can it be to import my project into a newer version of XCode?

Harder than I thought, I realized.

First off, XCode 8 requires the latest version of the Apple operating system on the computer. That operating system only works on new Macs. So to even be able to start XCode I would need a new Mac. Luckily I got my hands on one about a year ago.

Then… the version of Cocos2D I was using with RummyFight didn’t even compile in newer XCode so I had to download a new version of it. That version ONLY supported the new memory management system called ARC which RummyFight wasn’t built according to. Also a lot had been changed in Cocos2D so it would require a MAJOR rewrite of the RummyFight code to even use it. Then Apple has introduced lots of changes too in how to build an app. They have removed functions, replaced them with others, changed structure etc. Phew!

So in short:
To be able to submit an update of RummyFight I would need to
1. Buy a new Macintosh
2. Install the latest operating system
3. Install the latest XCode
4. Download a new version of Cocos2D
5. Adapt the RummyFight sources to all the changes in Cocos2D and in Cocoa (Apple’s system)
6. Change memory management to ARC in all my code (all 28.733 lines of it)
7. Update all graphics and textures
8. Get it to compile

And all this just to correct a spelling error or somthing.

So, pretty impossible mission, right?
Well… then it’s probably time for me now to reserve a table at Milliways – the restaurant at the end of the universe. Don’t you think?

(The app still needs a lot of rewrites and testing and changes etc before an update can be released but at least I feel an update is now possible – not impossible anymore)

06
Feb
15

Lots of database- and server problems lately

Just before christmas we had a major power out in our region and there was probably some kind of power spike or something when it happened since two of our three severs went completely dead afterwards. They didn’t even want to start anymore.

So to make sure RummyFight could be played again we borrowed a PC from a local computer store (Thanks http://www.databyran.nu), installed everything on it and got RF back online within 2 days, however a bit slow since now one server did all the work that two previously had shared between each other.

About 2 weeks ago we received two new permanent servers and we installed everything on them and configured them the same way the old ones were. We thought this would be the end of the problems but regardless of how we configured them, RF was running mysteriously slow.

So as a last resort we signed up to Google Cloud Services to use an online database in the cloud for all the data. Initially this looked like a great idea but then new strange things began to happen 2-3 times every evening where the database almost went to a complete standstill. We’ve been investigating this in collaboration with technicians at Google and they don’t know neither the reason nor the solution to the problem.

Yesterday I deployed a module I created myself that would cache and pool a lot of data and database connections and it seemed it solved some of the issues. Maybe I’m on the right track here. This day will determine if we can continue to use the cloud service so keep your fingers crossed. Otherwise we will have to figure out yet another idea to try out.

I just wish this can be solved soon so that I can continue focus on the app. It’s been 1.5 years now since the last update and I have had the new version at 95% ready for so long and it has such a large amount of nice new things and bug fixes in it I really would love to see it live sometimes.

I have it on my own phone and it’s great 😉

11
Apr
14

Moving forward

Well, I’ve now managed to get the app to start again, however it dies as soon as I touch it. Probably something easy to fix once I find out what’s happening. Anyway, this is an indicator of two things:
1. I will be able to get the app to work on Cocos2D v3.0 as well as on the new XCode
2. There will be a need for LOTS of testing of the app before it can be released again.
But that’s just something I will have to live with.

Too bad I also have two other great app-ideas I would like to create that will have to wait until I’m done with RummyFight. I do think those two ideas would be really fun to play but there are simply not enough time.

Ah, well. Back to work.




Categories