Install μlogger on CentOS 7 Server

If you are unfamiliar with μlogger, it is a handy Android application paired with a self hosted server application to keep track of your location. Or, in the author’s own words:

μlogger (‘micro-logger’) is an application for continuous logging of location coordinates, designed to record hiking, biking tracks and other outdoor activities. Application works in background. Track points are saved at chosen intervals and may be uploaded to dedicated server in real time. This client works with μlogger web server. Together they make a complete self owned and controlled client–server solution.

https://f-droid.org/en/packages/net.fabiszewski.ulogger/

You can actually just use the app on your phone to record yourself walking, biking, flying, etc., and then save your track as a gpx file for editing or viewing on any supporting app on your phone. But, if you wanted to save your adventures easily, or keep your adventures updating live for someone you know to view, then you can use the web server application as well. It works incredibly well, and if you are out of cell/wifi range, it will update with your personal server once you return, which is very useful.

The only problem was, while it had clear instructions for installation, they were written for someone smarter than me, so it took a bit of work to get it set up on my home CentOS 7 server. Hopefully, by writing this down, others can save themselves a little bit of a headache.

First, I would like to mention that this assumes you already are running a web server on your machine. In my case, I am running the Apache web server. So, I wont cover web server installing and setup here, but there are some great tutorials for that out there, like this one.

The instructions look like this, per the README.md:

  • Download zipped archive or clone the repository on your computer
  • Move it to your web server directory (unzip if needed)
  • Fix folder permissions: uploads folder (for uploaded images) should be writeable by PHP scripts
  • In case of development version it is necessary to build javascript bundle from source files. You will need to install npm and run npm install and npm run build in root folder
  • Create database and database user (at least SELECT, INSERT, UPDATE, DELETE privileges, CREATE, DROP for setup script, SEQUENCES for postgreSQL)
  • Create a copy of config.default.php and rename it to config.php. Customize it and add database credentials
  • Edit scripts/setup.php script, enable it by setting $enabled value to true
  • Make sure you have a web server running with PHP and chosen database
  • Open http://YOUR_HOST/ulogger-server/scripts/setup.php page in your browser
  • Follow instructions in setup script. It will add database tables and set up your μlogger user
  • Remember to remove or disable scripts/setup.php script
  • Log in with your new user on http://YOUR_HOST/ulogger-server/
  • You may also want to set your new user as an admin in config file.
  • Folders .docker/ and .tests/ as well as composer files are needed only for development. May be safely removed.

The biggest headache that I ran into was that the minimum requirement was for PHP 5.5, and CentOS 7 only comes with PHP 5.4 by default. However, that was easily fixed as root:

yum update
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
yum install yum-utils
yum-config-manager --enable remi-php55 [Install PHP 5.5]
yum-config-manager --enable remi-php56 [Install PHP 5.6]
yum-config-manager --enable remi-php72 [Install PHP 7.2]
yum install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo

This updated PHP to version 7.2, so you could skip that line if you didn’t want it, but I figured it might save me from having to update it in the future, so I went with it. Note that I did have to test out my other server functions that use PHP to make sure they were compatible.

After getting PHP up to date, I then downloaded the μlogger server repository from GitHub. It is pretty small, and only took a few seconds, even on my slow 10 mb internet to download it. I extracted in place, and went to work in the terminal, moving it to my web server location and giving it the proper ownership:

cd Downloads/
cd ulogger-server-master/
mkdir /var/www/html/ulogger
cp -Rav ./* /var/www/html/ulogger/
cd /var/www/html/
chown -R apache:apache ./ulogger
cd ulogger/

Now that it is in the right place, I needed a database for it to work with….

mysql -u root -p
enter password:
MariaDB> create database uloggerdb;
MariaDB> grant all privileges on uloggerdb.* TO 'EDITED_USERNAME'@'localhost' identified by 'EDITED_PASSWORD';
MariaDB> flush privileges;
MariaDB> exit

Keep in mind, the author of μlogger only suggests a few privileges, which he states in his read me as “(at least SELECT, INSERT, UPDATE, DELETE privileges, CREATE, DROP for setup script, SEQUENCES for postgreSQL)” however, as I monkeyed around with this, the script only seemed to run when I gave my user all privileges. Not sure if that’s just me, but here’s what I did, and praise God, it worked, because I was getting a little frustrated at this point. This write-up is the end result, not the “how many times I failed setting this up” story….

Now I needed to proceed and make a copy of the config file and edit it per the instructions:

cp config.default.php config.php
nano config.php
cat config.php 

<?php
/* μlogger
 *
 * Copyright(C) 2017 Bartek Fabiszewski (www.fabiszewski.net)
 *
 * This is free software; you can redistribute it and/or modify it under
 * the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, see <http://www.gnu.org/licenses/>.
 */

// This is default configuration file.
// Copy it to config.php and customize

// Database config

// PDO data source name, eg.:
//$dbdsn = "mysql:host=localhost;port=3306;dbname=uloggerdb;charset=utf8"
//$dbdsn = "mysql:unix_socket=/tmp/mysql.sock;dbname=uloggerdb;charset=utf8"
// pgsql:host=localhost;port=5432;dbname=uloggerdb
// sqlite:/tmp/uloggerdb.db
//$dbdsn = "uloggerdb";
$dbdsn = 'mysql:dbname=uloggerdb;host=127.0.0.1';

// Database user name
$dbuser = "EDITED_USERNAME";

// Database user password
$dbpass = "EDITED_PASSWORD";

// Optional table names prefix, eg. "ulogger_"
$dbprefix = "";

?>

The key part that went wrong here, was that there were several examples of how to set the “$dbdsn” or database name and location. I tried the ones included in the file, but none of them worked, so I web searched and found this line worked: $dbdsn = ‘mysql:dbname=uloggerdb;host=127.0.0.1’; so that is what I used in the end, instead of any of the included examples.

Now I needed to enable the setup script:

nano scripts/setup.php 

.... edited for space ....
// This script is disabled by default. Change below to true before running.
$enabled = true;
.... edited for space ....

With the setup script enabled, it was now time to get started! I opened https://EDITED_HOST/ulogger/scripts/setup.php page in my browser, and followed the on screen instructions, logging in with the username and password I made earlier, and everything went smoothly! Keep in mind, once the setup is done, you need to delete or disable the setup script to prevent it’s future use. So I just deleted it. Here is the end result when you bring up the web page https://EDITED_HOST/ulogger/

Sorry, I blurred everything out because I didn’t want any uninvited house guests! 🙂 If you want to see a great demo of it from the author, though, you can check it out from his web server on Heroku. Here’s a screen shot of it:

The mobile app is very simple to setup. Under settings, you simply input the username, password, and URL for your web server. You can then choose if you want it to auto upload as you go, or you can update it manually by pressing an upload button on the main screen.

I thought it best to mention that the original user you make is an administrator, and can edit several settings. I recommend that you make a new user with lesser credentials (non-admin) for use with the phone app. When you are logged in as the administrator (the first account you made) you can choose to make new users. This allows you to have lesser accounts for daily logging of activity. It also is handy if you are using this for your company as a way to track drivers/workers or if you have multiple family members, because everyone can have their own username and password.

Hopefully, this will save others using CentOS 7 a little bit of time to set this up!

Linux – keep it simple.

Is it “Go-Dot” or “Guh-Doe”?

Godot_part1

Since I decided to go with Godot, I’ve really, really been enjoying the experience. Of course it is a tremendous help to learn how to use it while making a game and following a great tutorial by BornCG on YouTube. This guy is a really great teacher! So if you are looking to learn how to use Godot, be sure to check his tutorials out! By the way, according to BornCG, it’s pronounced “Guh-Doe”.

godot_2

This is a slight detour from my intended project, but I like to have a successful path forward where I start using a new tool or programming language by using some sort of guide or tutorial. I find it helpful in making sure my environment is set up properly, especially if I get the same results as the instructor. So far, his tutorial is a pac-man/sonic like game where your sphere picks up coins and avoids enemies. I’ll try to include my final result when I get done!

So far, we have not used any native code, which you can program in yourself, using c++ or other languages. We’ve only been using GDScript thus far, which is an open source Python like language that is pretty simple to grasp. I look forward to seeing how we implement that, but either way, I’m certainly having fun!

Linux – keep it simple.

Which 3D engine to use?

Well, it’s time to pick which engine/sdk I am going to use to make my dice game.

Now the big question is what game engine to use. There may be many to choose from, but from a mobile app perspective, there seem to be only 3 that I would want to use. Of course, I’m ruling out Unity, because it is not open source. I’m trying to make an open source game, and I’d like to use open source tools so that anyone can openly tinker with it. I’m also ruling out several that work for Android, but the sdk is only available on Windows computers (irrlicht for example). That leaves the three main options of LibGDX, GoDot, Ogre, and jMonkeyEngine. There may be others, these are just the ones I know about.

Above is the quote from my post last week. I needed to do some research to decide which 3D engine and SDK (software development kit) to use to make my game. As I said, I’m sticking with open source tools, so that ruled out Unity and several other big name brands of SDK’s. I also am using a Linux computer, so it can’t be an SDK that only works on Windows or Mac. So, that leaves me with four main options that I could come up with. Obviously there are more options out there, but I’m trying to stick with ones that meet these criteria:

  1. Active development – Something that is still modern and will get updated over time, so I don’t have to learn a new SDK after I get the hang of this one.
  2. Guides and example code – I’m new to this, so I need it to have plenty of examples and guides to springboard off of.
  3. Active community – A place where I can go to ask questions if I get stuck.
  4. Easy Android integration – The whole point of this is to make an Android game, so it should be easy to get to that point.
  5. Java or C++ compatible – I don’t want to learn ANOTHER programming language just to make this game. I want to use and improve the tools I already have.
  6. Easy to use – It needs to make sense to me, or it will not work. If the API calls are ridiculous, I wont accomplish much.

So, with those in mind, I have sorted it out between my top four choices. Before I get to that, though, there are a lot of other options, but they don’t meet the above criteria, so I couldn’t spend my time on them, even though they may be great engines to use. That said, here is the breakdown of my thoughts on the top four choices, and what I plan to do. It’s not really a review, just my thoughts on what to do.

libGDX

I’ve actually used libGDX before, to make my open source game “Critical Velocity“, which was a 2D side scrolling space ship game similar to flappy bird. It does have an active community, is still being developed, and has lots of guides and tutorials and example code to draw from. It doesn’t have an SDK, you just add the java libraries to your app and use your standard Android SDK platform to build it, which is a big plus.

libGDX

The only downside is that it is made for 2D games with 3D kind of as an add on, which seems to still be under development. But, I would be familiar with it, since I’ve used it before, albeit for a 2D game. It also doesn’t have an “SDK” it is rather a library that you add to your own app.

jMonkeyEngine

There are quire a few perks to using jMonkeyEngine, it is actively being developed, and it seems to have a pretty good community behind it. There seem to be a lot of guides, documentation, and explanation of methods and classes, which is super helpful for me. It also seems to be a well fleshed out 3D engine, with a sustainable future and some neat features, most of which I am too new to understand. All the programming is done in Java, which is a plus for me, since it is a language that I am already familiar with.

jMonkeyEngine

I am not sure if I can see a downside to using this setup. It seems to be pretty solid, there are a lot of indie games made with it, and it even has book tutorials on Amazon, so this might be a good direction to go. I tried it out a little bit, and got confused right off the bat, but I’m not sure it that’s because of the interface, or because I am new to 3D game development.

Godot

Next up on the list is Godot. Hailed as “the game engine you waited for”, it seems pretty impressive. With a super permissive MIT license, an attractive interface, a visual editor, and full c++ support, this sounds too good to be open source true.

Godot

The only concern I have is that it will require some other languages as well. It seems to support c++, of which I am only a beginner, but used to. Yet it also uses GDScript as well, which is an open source scripting code they made just for this development SDK. Where I see that as a problem is it will probably only be useful inside of Godot.

Ogre

Last up is Ogre. Ogre seems to be very actively developed at the moment. So active, that it appears to have created some sort of rift between the different versions. From what I can gather by doing a little research (just my opinion based on what I saw), there is the old version Ogre1, which you can use to make Android games, and the new version OgreNext, which only works in Windows and Linux for now, with hopes of adding Android later.

If you use Ogre1, it appears to be more of a library that you add, like libGDX, but if you use OgreNext, it seems to be a full fledged SDK. So, I’m not sure about how I would want to use it.

It also appears that Ogre1 and OgreNext do not work the same, so if I learn Ogre1 to build my Android games, will I need to relearn OgreNext so I can continue with that in the future? Perhaps that’s just my perception, but my perception being my reality, I don’t think I can put in double the effort to learn how to make 3D games.

Final result

I think I am going to give Godot a try. However, if it doesn’t work out, jMonkeyEngine is the runner up. Ogre seems to be undergoing some massive changes, and I’d like to work with something that is a bit more stable, but libGDX doesn’t seem to have all the “bells and whistles”, seeing that it is just a library to add to your current development.

I struggled this week between jMonkeyEngine and Godot, but in the end settled with Godot because the interface was so intuitive. I was able to walk through a few things in no time. Literally, within minutes and without any documentation, I loaded someone else’s project and was playing a game and editing code. I am also looking to expand my c++ skills rather than work on my Java. So, Godot it is, at least, for now….

Linux – keep it simple.

Dice, anyone?

LowPolyDice

Now that I’ve completed the low poly course from Udemy, I’m ready to start using my fledgling, but newfound skills in some form of application. That said, the most fun and easiest way that I can imagine using 3D models is in some kind of game. The question is, what to make?

If you’ve been reading this blog for a while, you may remember that I once made a dice game app called “Ship, Captain, and Crew”, based on the sailor dice game of the same name. So, I’ve decided to revamp that project by creating a 3D version of the app. Essentially, I’ll be starting from scratch, but utilizing the same game mechanics that are in the first game.

The two big things I think I will need are the 3D objects and then some form of 3D game engine to render it. Today I completed the first part, which was making the dice. It took me about an hour to throw this together, but I think it will do as a low-poly die for the game. In theory, I will just use 5 of them during the game itself.

Now the big question is what game engine to use. There may be many to choose from, but from a mobile app perspective, there seem to be only 4 that I would want to use. Of course, I’m ruling out Unity, because it is not open source. I’m trying to make an open source game, and I’d like to use open source tools so that anyone can openly tinker with it. I’m also ruling out several that work for Android, but the sdk is only available on Windows computers (irrlicht for example). That leaves the four main options of LibGDX, GoDot, Ogre, and jMonkeyEngine. There may be others, these are just the ones I know about.

So, now I need to do some research and see which one will work best for me. I’ve never made a 3D game before, so this might take a while….

Linux – keep it simple.

Still Gapp-less?

Trebuchet3

Back in July, I decided to go Google App-less, or gappless. Cold turkey. No baby steps, just quit using Google Apps on my phone. Of course, this is possible only with custom ROMs, and then I don’t install the Google Apps packages into those ROMs. I don’t want to belabor the point, but the one thing I want to say about going gappless is: I can’t even tell they’re gone.

I thought it would be a little inconvenient, or that it would be difficult to work with on a day to day basis, but the truth is, since going gappless, I don’t even notice a difference. Other than using a few different apps to do the exact same thing I was doing before, nothing has changed. Kind of makes me wonder what all those Google Apps were for anyways….

Truth be told, Google does make some great apps. But most of the time, even before going gappless, I wasn’t using them anyways. For instance, GMail is a great app, but I have multiple email accounts (because of work, etc.) and so I was using a different email app (librem, K-9, even AquaMail at one point) for all of my phone email needs.

The only big ticket item was the Play Store, which now I realize I can get just about any app (well, any app I ever needed) from F-Droid, Aptoid, or Amazon Apps. The other contender being Google Photos to store all of my pictures. Of course, if you’ve been around my blog a while, you’ve surely seen my home piwigo photo storage system, so I wasn’t using Google Photos either.

Overall, looking long term at my phone these past few months, my battery typically has a higher charge at the end of the day. Typically I was seeing around 60-65% at the end of the day, now I see about 70-80% when I get ready for bed. My data plan uses less data, usually in the 500 MB to 1 GB per month range over these past few months as well, which is a plus. Also, my phone uses about 200 MB ram to run during the day.

I’m actually not writing this to bash on Google or their apps. They actually work really well if you use them. I am writing this to answer that question that I’ve been asked dozens of times lately: “Are you still gappless? How’s that working out for you?” Truth is, yes, and I don’t even miss it.

Linux – keep it simple.

Home photo server, part 2: Apache, phpAlbum, and Piwigo

Last time we talked about how to set up the domain name with DDNS for free, and then using very secure FTP, vsftp, and SyncTool (the Android app) to automatically move photos from your phone to your home server. But that’s only half of the battle. One of the big perks to using Google Photos is that you can browse them anytime from anywhere. You can share them with friends, make comments on them, and other socially related things. We need a way to do that from our home server, too.

There are many, many methods to accomplish this, and I tried several, but I’d like to point out two options that worked really well, were simple to use and set up, and used little to no JavaScript. There are several reasons why one might not want to use JS, like security, etc., but I’ll save that for another post. The two best options were phpAlbum, which is 100% JS free, and Piwigo, which only uses JS for some display themes, I chose one without it and it seems to work just fine.

Either way, I needed a web server, so I installed Apache.

# yum install httpd

# systemctl enable httpd

#firewall-cmd –add-port=80/tcp

# firewall-cmd –add-port=80/tcp –permanent

Right out of the box, you could browse to my web server. Of course, it was insecure and it only displayed the main page. I’ll break down adding certs and making it TLS and SSL compliant in another post. I was ready to set up my router, make sure you route that traffic to your server! Since that is rather router specific, you’ll have to look that up on your own, but there are tons of guides on it. Now it was time to install a photo gallery web server.

So, first on the list, I tried phpAlbum. It worked great and seems to be a good fit, provided that you have a smaller photo collection. One big plus is that it doesn’t need a MySQL database or anything. The only downside: once I surpassed 8000 photos, and numerous folders, it seemed to not be able to keep up. So, for a short time I got around this by setting up multiple web pages, each running a unique instance of phpAlbum, each with it’s own set of photos. This was simple, really, I made one for a couple of years worth, and one for the next 3 or 4 years, and then had a main web page that linked to the different ones. This is a bit tedious and cumbersome though, but wasn’t too bad if you have a lot of static images.

Since it is so simple, and has a good installation guide, which you can read here, I’ll be very brief about how I set this up. You can also click here for a phpAlbum demo.

# yum install php php-xml php-mbstring php-gd

# yum install ImageMagick

# yum install unzip zip

After downloading the latest phpAlbum zip from their website, unzip it and edit config_change_it.php to your needs with nano or vi, basically by setting the data directory and the photo directory, and rename it config.php. Now copy the entire directory to /var/www/html. So in my setup, it was /var/www/html/phpAlbum/ with all of the files in it.

Next, chmod 777 the cache, data, and photo directory inside your folder, so you can write to it with other users (the uploading functions). Then:

# chown -R apache:apache /var/www/html/phpAlbum

so your web server can own it (since I’m using Apache as the web server). Now all you have to do is navigate to http://yourDomainNameIPaddress/phpAlbum and you will be greeted by a login, to which the default is admin and admin for the username and password. Once your in, it will ask you a few questions, and you can be up and running in a few minutes! It worked really great, like I mentioned earlier, when I had a smaller photo collection (under 8000 for me, but your mileage may vary).

Since it was struggling with more photos, I decided to switch to Piwigo. You can check out a demo of it here. There is a really, really great guide on TecMint, that I drew from when putting this together, but it was relatively simple. Start by installing the dependencies – note that a lot of these were already installed for phpAlbum, and I’m not 100% sure you need all of these, but this is what I installed:

# yum install php php-xml php-mbstring php-gd wget unzip zip ImageMagick python python-tk python-psyco mariadb-server php-mysqlnd

Now you need to enable and set up your MySQL/mariaDB:

# systemctl enable mariadb

# mysql -u root -p
MariaDB [(none)]> create database piwigo;
MariaDB [(none)]>grant all privileges on piwigo.* to ‘piwigouser’@’localhost’ identified by ‘pass123’;
MariaDB [(none)]>flush privileges;
MariaDB [(none)]>exit

# systemctl restart httpd

Be sure to use your own usernames and passwords. I don’t recommend the defaults! Then you need to download Piwigo and unzip it, placing it in your Apache web server root directory. After you put it in place, you need to set the proper read and write permissions, as well as ownership:

# wget http://piwigo.org/download/dlcounter.php?code=latest -O piwigo.zip
# unzip piwigo.zip
# cp -rf piwigo/* /var/www/html/
# chown -R apache:apache /var/www/html/
# chmod -R 755 /var/www/html/
# chmod -R 777 /var/www/html/_data/

# systemctl restart httpd
# systemctl restart mariadb

Now it’s up to you how you want to handle moving the pictures we automatically uploaded to the server into the Piwigo directory. For instance, you can have your photos upload from your phone to your home directory, and then make a cron job or script, or manually put them into your Piwigo directory. One benefit of this is deleting blurry or useless photos. I like this option best, but that’s my opinion.

Another option is to set the /var/www/html/galleries photo permissions to be writable/readable by others, or add your user to the group and upload your photos directly to it. I tried this as well, and it works good, too. Either way, now all you have to do is use your web browser to navigate to your server, and you should see the Piwigo first login/setup screen.

Choose your options, such as language, etc., tell Piwigo what the MySQL/MariaDB is called and what that password is, and you should be up and running in no time! Now you can log into the web interface as the admin user (that you just set) and start choosing themes, uploading photos with the web app, or syncing the galleries folder for the photos you put there via FTP or moved manually or scripted.

piwigoPublic

In this screenshot, you can see the light theme that I went with, and how there are some photos available for the public to see. If I log in, then I can see the rest of the pictures:

piwigoPrivate

You can have more users and give each user access to certain files, folders, or groups. Groups is nice because you can give “family” the option to see this, and “friends” the option to see that. You can control everything from the web admin screen:

piwigoAdmin

Another plus to Piwigo is that there are several Android apps out there, some paid, some free, some open source. So there are options, but quite honestly the web browser of Android works great, since Piwigo has two theme settings, one for desktop browsing, and one for mobile browsing as well. So you can have two different themes, one for each desktop and mobile, to maximize what works best for you.

There’s still a few things to cover though. Right now, it is only using port 80 for unsecure web traffic. We definitely want to use secure http on port 443, so we will cover certificates and security next.

Linux – keep it simple.

Android meets Arduino!

As you guys know, I don’t really do “product reviews”. But if I find a handy tool, and use it, then it is fun to share that info with others. One such tool is Bluino Loader, an Android app that lets you create Arduino files, upload them to your boards, and even monitor the serial connection over USB. It’s pretty handy!

As with any “code from your phone app”, it is a bit tedious to type a lot of code with the Android keyboard. So I don’t use this app a lot when it comes time to create code. One of the big things that I like to do with it, though, is to monitor the serial output over a USB OTG cable.

Using the OTG cable, I can hook the Arduino Uno board directly to the phone, which also powers the board. Then I can open up Bluino Loader and click the icon at the top to monitor the serial connection. It can’t get much simpler than that. Within seconds I have serial data coming in and being displayed in the terminal. I even used it to test out the 433 MHz transmit and receive functions from my last test project. Worked like a charm!

Linux – keep it simple.

Android Remote Control through ADB

Today, I stumbled on perhaps the most ingenious use of ADB ever:

Remote control your Android phone through adb

A program and write-up by Marian Schedenig, that they shared on their website. This is perhaps the best adb tool I have ever seen, in that it takes three simple principles and puts them together to allow you to remote control your phone over ADB with your mouse, without ROOT permission!

output3

Here is a small gif that I put together from a screen recording of me using this awesome java tool. Essentially, it uses adb to take screen shots of the phone. Then it downloads the screen shot and updates it’s display. Finally, when you click on the screen, it sends an x/y co-ordinate to the phone over adb to tell it you swiped or clicked! It is absolutely brilliant!

The updates are a little slow, and you do have to edit the config file for your specific needs, but it works great, and is a really useful tool if you broke your screen or have touch screen issues, or just need to display your screen for an audience to view while you press buttons or work with apps. Since it is written in java, it is cross platform as well!

Linux – keep it simple.

Text field types to capitalize sentences…

device-2018-09-10-130014

I recently received a comment from a Just Notes user about how much they loved the simplicity of the notes app. However, they also pointed out that the text field that you type into doesn’t automatically capitalize sentences or names, and somewhat lacks a bit in terms of use.

He was right.

I typically use this for typing grocery lists, and things that don’t turn out to be complete sentences. So I noticed, but it didn’t really matter to me. I realize that others may use it differently, so I wanted to fix this.

So I did.

You can check out the commit here, where I updated to the target api of 26 (per Google’s requirements to be listed on the Play Store now – *sigh*) and changed the text field type. Here is the only thing that actually changed in my app, from this:

android:inputType=”textMultiLine”

to this:

android:inputType=”textCapSentences|textAutoCorrect|textAutoComplete|textMultiLine” />

And that’s it. That makes it work with auto correct, auto complete, and to capitalize sentences!

Linux – keep it simple.

Triple check that, will ya?

device-2017-03-08-124806A long long time ago
I can still remember how
That App used to make me smile….
And I knew if I had my chance
That I could make those dice dance
And maybe they’d be happy for a while….

Uh, wrong lyrics. Actually, it was quite a while ago that I made the Android app, Ships, Captain, and Crew! After the move from GitHub to GitLab, I decided to look over some of my old issues that were imported with GitLab’s great import tool. Among them, I found two issues for this old app that I had made.

The first was that of an issue with screen rotation causing the app to restart. I quickly fixed that by just setting the activity to portrait mode in the manifest file. You can check my commit if you need details.

The second issue was a bit more complicated, in that there was a problem with checking the dice for a ship, captain, or crew. Essentially, if you rolled a 4, 5, 6, 1, and 3, it would say you only have a ship (the 6) and no captain (5) or crew (4). Obviously that’s wrong. The issue is that you need a 6 before you can keep a 5 or 4. And since the dice were checked in order, when it looked at the 5 or 4, it did not have a 6 yet, so they were not “kept”.

This is how I fixed it:

for (int i = 0; i < 3; i++) {

// Check three times.

myNumber = firstDie;

diceCheck();

if (waschecked){

firstnotchecked = false;

}

dieOne.setImageResource(id);

myNumber = secondDie;

diceCheck();

if (waschecked){

secondnotchecked = false;

}

dieTwo.setImageResource(id);

myNumber = thirdDie;

diceCheck();

if (waschecked){

thirdnotchecked = false;

}

dieThree.setImageResource(id);

myNumber = fourthDie;

diceCheck();

if (waschecked){

fourthnotchecked = false;

}

dieFour.setImageResource(id);

myNumber = fifthDie;

diceCheck();

if (waschecked){

fifthnotchecked = false;

}


dieFive.setImageResource(id);


}

As you can see,  I told it to check the dice, first to last, three times. Yes, this is ugly and poor programming. Actually, I was almost ashamed of this early work, it looked so congested and terrible. However, my goal today was the quick fix, so that’s what I did. Hopefully, the update will be available on F-Droid soon, so you’ll have to check it out!

Linux – keep it simple.