Apps Need Room To Breathe!

Share if the site was helpful

Apps Need Room To Breathe!

Android is a complex operating system.  There’s a lot more variable when developer for Android.  Things are unpredictable when it comes to knowing what phone your user will be on.  There’s literally no limit to how many different kinds of phones could be running Android on a given day.  If you don’t know what you’re doing this can be dangerous for your layouts.

How so?  Doesn’t everything work the same from phone to phone?  Well, no actually.  Things function very similarly, but different phones have different characteristics that can drastically change a user’s experience.  Take screen size for example.  You could design an app and have one user download it on a phone with a 4’’ screen and another on a 6’’ screen.  This may not sound like a huge difference (2 inches is rarely a big decider life), but when it comes to a screen size that’s literally 50% more screen space on one device than another!

How things can go very, very wrong:

If you don’t take different screen sizes into account, then users will most likely miss out on important info. When you’re first learning about how to develop Android apps you’ll most likely use LinearLayout a lot to organize your apps.  This layout takes one view (text, image, button, etc.) and then lines up the next one in a list side by side.  Or you can change it to go vertically.  Either way the end result is a neat row/column of views.  Here’s an image to help you visualize:

But what happens if when your developing you only test the layout on your phone (let’s assume its huge).  Things may look great to you, but when you publish the app and someone with a smaller phone uses it this is what they might see:

How we can prep for things to go very, very wrong:

Trust me as I made this mistake on the first app I ever published: It’s not a fun mistake to make.  Your app is a work of art.  It’s something that you created from nothing and want to show off to your friends, family, and the world.  So when you have someone download it and instantly their greeted with a funky looking layout…well it’s not the best feeling.  Luckily, we can learn from our mistakes and prep for them in the future!

There are situations where you want to use LinearLayout and there are situations where its best to avoid it.  Sometimes you may want to keep the row/column but add scrolling capability to it instead.  Android developers have experienced all these scenarios, and that’s why there’s more options than just LinearLayout.

Layouts like ConstraintLayout and RelativeLayout allow you to position views in relation to one another as well as to their parent.  So you could position pictures on your screen to “attach” to the right or left side, and make your layout look a lot more professional.  That’s of course just the tip of the iceberg though.  There are different screen densities to account for when choosing what images to use.  And you can also have portions of your screen appear/disappear by using fragments. Don’t worry we’ll have posts on both of these topics coming up soon!

If you’re interested in learning more about styling your apps for different screen sizes and how to make your layouts ready for professional use, checkout Phonlab’s Android App Developer course!

 

Google Pay: Caring Is Sharing

Share if the site was helpful

Google Pay: Sharing Is Caring

Earlier this year Android Pay and Google Wallet combined forces to create Google Pay, a one-step payment process for Android users.  The app has featured online payments with certain websites/apps by initially linking a credit card and then checking out in the future with one click. More technologically impressive it uses NFC (Near Field Communication) to allow users to hold up their phone at a cash register and buy things in person too.

Google Pay seeks to make users lives easier by removing the hassle of reaching into you wallet/entering checkout info every time you buy something.  Yet the adoption rate for it has been…sub-optimal.  So far we’ve seen about 6% of total smartphone users give Google Pay a try.  It’s a growing number, but it’s still not very big.  If it’s because Google Pay doesn’t do enough for users, then it may start growing faster.

So what’s new?

Today Google announced some new features for the app that make it more useful.  The biggest of these is that you can now use Google Pay to send money to friends.  With apps like Venmo, PayPal, and the CashApp this is nothing new, but it’s necessary for the Google Pay to become relevant as it’s one of the primary ways younger generations pay one another.

And if you haven’t used cash sharing apps like these before GET ONE.  They’re essentially the staples easy button for splitting bills at restaurants and paying back friends.   Google Pay has a challenge of gaining traction in this sector since there are already a few established apps and sharing apps are only as useful as their adoption rate.  But then again, it’s Google and they choose what apps comes preloaded on Android phones.  Chances are they’ll be alright.

But wait there’s more!

Another new upgrade for the app is that it will be supporting boarding passes and event tickets.  Companies like Southwest and Ticketmaster will be incorporated into the app to allow users to take one step closer to a one-stop shop.  These tickets will update with real time information if something like a flight delay takes place, and they’ll work alongside any loyalty cards you have.

The updated Google Pay app is rolling out today, but it will be a few weeks until it reaches everyone who uses it.  The long term goal is clearly for Google Pay to become your go to app for any circumstances. I’m certain we’ll see some more new features come up in the news soon, and I’m also sure you’ll be able to read about them here!

What are your thoughts on Google Pay’s changes?  Is it still lacking something essential for success?  Let us know in the comments below.

The Six Degrees Of Activity Lifecycles

Share if the site was helpful

The Six Degrees Of Activity Lifecycles

As an Android developer, one of the most fundamental concepts that you’ll learn about is Activities.  Activities are a Java class that focus on a single thing that users can do.  Many involve user interactions, and in most apps on your phone you can think of each page of the app as an activity.  Open Gmail and see your list of recent messages? Activity.  Click on one of those messages to open it in a new page?  Activity.

Activities are everywhere in Android development, yet many developers that are just starting out don’t fully understand how they function.  You might be able to get by without a full understanding, but this can be lethal to your app as it expands and becomes more complicated.  Lack of understanding opens up Pandora’s box for things to go wrong with memory leaks and debugging errors down the road.

Diving In:

So let’s take a blog post to discuss the Activity Lifecycle in a little detail.  We won’t get stuck in the weeds, but cover the basics enough that you understand what’s going on under the hood and can prep for smooth app development.

Just like humans have a lifecycle from birth to death, apps have a lifecycle they follow from when their first launched to when the user closes them.  There are six methods that can be called to change the state of an activity in Android:  onCreate(), onStart(), onResume(), onPause(), onStop(), and onDestroy().  At first glance these may seem similar if not identical to one another, but understanding the differences is key to a successful user experience.

onCreate():

This is the first of the 6 lifecycle methods called in an activity, and its invoked when (you guessed it) the activity is created.  In this method startup logic that should only happen once during an activity’s life takes place.  Examples of this might be to bind data to a list, or to instantiate class-scope variables.  The bottom line is that this is called once and only once.

onStart():  

Immediately after onCreate() comes onStart(). The start state of an activity occurs when it is made visible to the user.  This is where logic goes to prep the activity to enter the foreground and become interactive.  In other words the User Interface (UI) is taken care of here.

onResume():

Yes I know, it’s three different methods whose names make it sound like they all do the same thing.  Here’s the key difference with onResume() though.  onResume is called when an app has already been created and comes into (or back into) the foreground.  An activity is constantly interactive as long as it’s in the foreground for the user.

But what if your app includes a pop up message over the activity?  Well now that pop up has the foreground.  Your activity from before will enter the onPause() state (keep reading!) until that pop up goes away.  Once it does your app will resume, and thus the onResume() method will be called again.   For example, let’s say your playing a game and an alert interrupts it.  Obviously we don’t want the game to keep going when the user can’t see it, because that would be incredibly frustrating when the user returns and finds out they died while they were way.   So we call onPause() when an activity loses focus and certain resources need to either be cleared or put on hold.

onPause():

There’s really not too much more to this one other than what I said before.  It tags in and out with onResume() to create/delete resources when needed depending on if a user has focus.  It’s where the magic happens if you do things right, and where things go noticeably wrong if you don’t.

onStop():

When your activity is no longer visible, it has stopped.  This is different from onPause() in that your activity is entirely shrouded.  Instead of a pop-up that might cover half of the screen, a new activity may have taken place and covered your current one completely.  This is essentially where the app has can completely remove unused resources that the user won’t need when returning to the activity again.

onDestroy():

And finally comes our 6th method that wraps everything up.  This is called right before an Activity is destroyed, and as such you want nothing left hanging around.  If you forget to close up a loose end in onDestroy(), your app may begin to suffer from memory leaks and eventually bog things down.  Bottom line is that all resources should be released here if they weren’t in onStop().

These 6 methods essentially bounce the user between the two states of in the user’s foreground and in their background, but there are intricacies that go a lot deeper between them.  As such properly knowing when to implement each of them can be a life saver for your apps, and a huge time saver for you when you’re building things out and want to know what’s going wrong.

If you felt lost at all along the way of this blog, then you should check out Phonlab’s Android App Developer Course!  It’s a great way to go from writing your very first line of code up to publishing our own apps on the Play Store.

Samsung Is A Go For Android Go

Share if the site was helpful

Samsung Is A Go For Android Go

We’ve talked about Android Go a few times here before.  It’s Google’s movement to bring budget phones to the rest of the world by stripping down the software and limiting specs.  There’s been a bit of buzz around the movement recently, and earlier this week a leak has revealed some details about Samsung coming into play.

The Specs:

That’s right, Samsung may be getting into the budget phone game with a 5-inch display and Samsung’s mid-range Exynos 7570 SoC processor.  For reference this compares pretty similarly to Samsung’s Galaxy J3 in terms of size and capability (see the following image).  The phone will come with 1GB RAM and 16GB of storage as well, following the Android Go system of making things high quality but low memory.  And of course, as with other Android Go phones the operating system version will be Android 8.0 (Oreo).

The SamMobile sources behind this leak said that the new phone (model name SM-J260G) is currently being tested in dozens of markets around the world including the UK. And everything about this leak falls in line with earlier reports that Samsung is testing three new mid-range smartphones.  Not much has been revealed about these other than their model names (SM-J260F, SM-J260G, and SM-J260M) and that they will all most likely be part of the Android Go movement.  So it seems Samsung is ready to dive into Go headfirst.

Android Go’s Future:

Android Go was announced back at MWC in February this year, and since then we’ve seen multiple phones get in on the action.  The idea is to bring incredibly affordable phones to people that otherwise couldn’t afford smartphones, but still give them all the newest in terms of software.  The was this is possible is by limiting other specs on the phone and putting in less preloaded apps (not exactly a bad thing!). Android Go is just getting started, but it aims to provide phones for the next billion users around the world, and I’m excited to see where it’ll go from here.

What are your thoughts on the new Samsung phone that we may be seeing soon?  Let us know in the comments below!

Improved Security Or Less Freedom? APK Updates

Share if the site was helpful

Improved Security Or Less Freedom? APK Updates

Earlier this week a small change rolled out to the Google Play Store.  It’s one that you likely won’t even notice, but for those who have it’s tough to decide whether the shift is good or bad.  What change?  Just a small string of metadata for apps.

Google is adding a security string of metadata to all Android APKs (the file format android apps are stored in).  This string will come along with the usual app and be used to verify that apps are distributed through the Play Store or another approved channel.

But why?

The reasoning is (of course) for security purposes.  Users will be able to verify that the apps their downloading aren’t malicious apps seeking to wreak havoc on your system.  There are plenty of apps that have posed as secure looking every-day apps when in reality they were doing other things under the hood (such as mining bitcoin).  This new metadata will supposedly help catch apps like this and ensure that any apps users are downloading are coming from a safe place.

We’ve talked before about how android apps are pretty secure through their information silos.  Apps must use a content provider/resolver to access information from one another, and in order to get access to your serious information (contacts, messages, pictures) apps are required to request permissions that must be explicitly granted by the phone’s owner.  That being said it’s still not a good idea to go around downloading every app you can just for the heck of it.  Security should not encourage reckless behavior.

So what’s the issue?

So why the controversy?  If this new string of data will help keep our phones more secure why could people be opposed to it?  Well the new string is essentially DRM (Digital Rights Management).  As with media services, there’s potential for companies to abuse DRM to choose how and when you use their product.

Let’s say for example you download an app and like it how it is.  A new update comes out and you hear horrendous things about it like it makes an ad pop up every 5 seconds (a terrible marketing strategy).  Naturally you would try to hold off on updating to this new version as long as possible.  Well with DRM it might be difficult/impossible to tinker with the app to remove ads, and a developer could potentially force you to update to the new version by altering the metadata.  It’s a win for mobile app security, but it also invites misuse.

It’s not easy to say if this is a big deal or simply a step in the right direction for security, but it also hasn’t been in the limelight for long.  What are your thoughts on this change to coming apps?  Let us know in the comments below!

 

 

The Pixel 3 Leaks Just Keep Coming!

Share if the site was helpful

The Pixel 3 Leaks Just Keep Coming!

 

If you’re a phone junky then you’ve probably been following all the buzz surrounding the upcoming Pixel 3.  And if you haven’t been but are interested in catching up, then you’ve come to the right place.  Rumors and leaks galore have been floating around this week and late discussing what the Pixel 3 and Pixel 3 XL have in store for users.  Let’s discuss:

It’s Huge:

I’m not just talking about the hype.  The Pixel 3 and Pixel 3 XL are going to be larger than their predecessors (is anyone surprised?).  Measuring in at 5.3’’ and 6.2’’ respectively these phones will be giving the iPhone X a run for its money in terms of screen real estate.  And also much like the iPhone…yep you guess it, there’s a notch thrown into the mix.

Just like almost every other android phone since the iPhone X’s reveal the notch seems to be playing a big role in design practices.  A few images were images have been posted on the XDADeveloper’s forum showing a Pixel 3 rocking a notched display, dual front cameras, and a back that appears to be made of glass.

New features:

Why glass on the back?  Well this has led to speculation that wireless charging may be coming back into play.  This feature was discontinued a few years back in the Nexus series after Google’s acquisition of HTC.  The argument was…not the strongest.  Google argued that Nexus phones had too much z (thickness) with the wireless charging, and that USB Type-C charging was a much simpler solution.  Maybe more efficient, but its definitely not as cool!

Of course we have to take these leaks with a grain of salt.  The Pixel’s camera is a good demonstration of this.  There’s been a lot of back and forth about whether one or two cameras are in store for the new device.  Leaked images have confirmed both cases, so its hard to know what’s really true and what is just a wannabe, but a series of images leaked by 9to5Google show a single rear camera on a Pixel 3 prototype.  This leak matters as the phone was sporting a mystery Google logo, so it gains another ounce of credibility.

Whatever the case, Pixel’s are known for their phenomenal cameras, and when the Pixel 2 came out its camera blew us away.  Since then quite a few other phones have scored higher on DxOMark (a image quality rating site), but at the time the Pixel 2 was the leader.  So odds are the Pixel 3 is going to exceed expectations again and top the charts in this manner.

New Software:

The Pixel 3 is also expected to be the first official phone rocking Android P software.  So new features like RTT-Wi-Fi and auto-adjusting batteries will open new possibilities for both users and developers.  Android P is currently available for beta use if you’re interested in exploring it early, but if you’re planning on purchasing a Pixel 3, you’ll have it in your hands before you know it.  There’s no official release date set right now, but the popular opinion is this October.  So close and yet so far.

What are you hoping the Pixel 3 will have that other phones are lacking?  Do you think it will be a let down or a leader in the industry?  Let us know in the comments below!

Changing Your Software In A Flash

Share if the site was helpful

Changing Your Software In A Flash

Android P is the hot new software that just hit the market, and as such those ahead of the pack will be scrambling to get it on their phones.  This doesn’t mean that they have to go out and buy a phone with the newest software on it though.  By flashing your current phone you’re able to gain access to either the newest features on the market.  Or if you’re feeling nostalgic you can flash your phone to older versions as well.

The term “flashing” may be a new one to you, but if so don’t worry.  All it essentially means is that you’re loading a different version of software onto your operating system.  (Although you probably figured that out from the first paragraph).  So flashing forward can get you fancy new features, but why would you go backwards?  One reason might be to conserve battery power.  A newer version is bound to drain your battery faster, so the trade off may be worth it. 

WARNING:

Now here’s where I throw out the very important disclaimer.  Flashing your phone will erase all data from the device, and doing things wrong may brick your device. This means that if things are done incorrectly or get interrupted then you may render you phone unusable.  This is why its highly recommended to only flash a phone when its full charged.  If somehow the phone died mid process things could get tricky quickly.

That being said flashing can offer some really cool features, so if you’re careful and follow a guide to do it properly the results are worth it.  So how do you do it? There are a few things that you’ll need to make sure you have on your computer before starting the process, but overall the steps are simple.  In all flashing shouldn’t take you more than 30 minutes (and that’s moving slowly following a guide).  Google offers a step by step instructional guide on its docs page, but in order to follow this you’ll have to have the following tools:

-Android Debug Bride (ADB) and Fastboot

-A phone set to developer mode

-The correct image for the version you’re flashing to

Flashing can be a really cool experiment to undertake if you’ve never done it before and want to change how your phone works.  Just make sure you proceed with caution and charge your phone in advance.  If you really want to know more about it and get support on flashing/rooting your device Phonlab offers a course that covers just about every phone you can imagine!

Keeping Your Keys Safe

Share if the site was helpful

Keeping Your Keys Safe

At some point in your app development career, you’ll create an app that has secrets.  By this I mean there will be keys inside that you want to keep secure from prying eyes.  If someone else gets a hold of your private info, the results could be disastrous (or expensive).

Let’s say your app uses Amazon Web Services and your monthly bill runs about $350 a month. That’s fine because you’re making the money back through app usage.  That is, until a 3rd party gets a hold of your secret key and decides to use it for their own purposes.  Then when your next bill comes due you find that you’re being charged for $50,000.

Not an exaggeration.  This exact scenario actually happened.  So the lesson is painful but memorable: secrets should be kept secret!  Let’s use this blog to talk about a couple ways people tend to store their keys and what you should avoid.

Avoid pushing keys to github:

I’ll start with what may sound obvious.  That sight that you put all of your code onto so that people can publicly view it?  Yeah, don’t put your secret keys up there.  This sounds obvious, but recent studies have shown thousands upon thousands of keys are available on public git repositories.  It’s possible your using a free service and don’t care, but if you’re being charge even a dollar for the service you’re using, keep it close to your heart.

Storing keys as basic Strings:

DON’T DO THIS!  Storing a key as a simple string is just asking for trouble.  There a couple issues behind this, but first and foremost is that it’s incredibly easy to access.  If you read our primer on reverse engineering apps then you know that it’s possible for 3rd parties to decompile your app and look at its code in its (almost) original form.  Storing a key as a string means the hacker just has to glance over your code and look for something that looks like a key.  Then it’s theirs and they can do what they want until you change it. 

Defining keys in build.gradle:

This is better than storing your keys as Strings in any old file, but the end result is unfortunately similar.  A lot of people put their keys in build.gradle in such a way that it’s created in the BuildConfig file of your app.  The bright side is your gradle file isn’t decompiled along with the rest of your app, so secrets are safe in there.  The downside?  Well, that BuildConfig class they were just created in isn’t as secure.  Again, our Strings are exposed in a very simple to access way.

Securing keys with Android NDK:

Let me take a second here to say something important: There is no such thing as absolute security.  If you’re going to have a secret in your app, all you can truly do is make it incredibly difficult to find.  Take the proper precautions to keep things safe, and a hacker will have to decide if it’s worth the time/energy to get to whatever is hidden.

With that said, the Android NDK (Native Development Kit) can help us use C and C++ code with Android.  Why would we want to do this?  Well for starters NDK libraries can’t be decompiled, so the information inside is a lot harder to find.  There are ways to access this code all the same, but we won’t go into them here.  It’s not perfect, but this will throw quite a few entry level hackers off your tail.

Make your code complicated:

This one again goes to what I said earlier about complete security.  It won’t happen, but you can make a hacker’s life hell by making your keys as hard to read as possible.  Let’s take a very basic example:  If your key was 123456, instead of storing that, you could make it the sum of the strings “12”, “34”, and “56”.  How you can break this up depends on how creative you can get, but there really isn’t a limit.  It just means more work for you both upfront and down the road to ensure you understand everything your code is doing.

Keeping keys safe is crucial for a large apps success, so you need to take precautions to avoid disaster.  If you have any suggestions for great ways to hide Strings inside your app let us know in the comments below!

Google I/O, Until Next Year

Share if the site was helpful

Google I/O, Until Next Year

Well Google I/O is a wrap everyone, and if you tuned in then hopefully you left with some cool takeaways.  If not then don’t worry, that’s what we’re here for.  When the conference first kicked off we wrote about day 1 and its highlights, but obviously the fun didn’t stop there.  The following is a crash course selection of (in my opinion) the most important and amazing takeaways for and android junky.

Flutter:

If you’re an android developer, then your undoubtedly familiar with Java and segueing in to Kotlin.  You might not have heard about Flutter before though.  It’s Google’s mobile app SDK for easily creating high quality apps on both Android and iOS devices.  Written in Dart (a language developed by Google as well), Flutter works with existing code and is used to develop at ridiculously high speeds.  Here’s a great video from Google I/O that goes more in depth on how to use Flutter to enhance your material design.

Duplex:

Now this one blows my mind, and I know I’m not alone here.  When you think of a sci-fi future it’s reasonable if computers playing our personal secretaries pops into your mind.  This seems to be the present now. 

I’m very interested to see how Duplex functions successfully in real world applications, but the Google 2018 keynote showed a quick performance of the Google Assistant booking a haircut appointment for Google’s CEO, Sundar Pichai.  From an outsider’s view the conversation was impossible to distinguish from an everyday conversation between two people, and when it was done the Google Assistant confirmed to Sundar that the appointment had been booked and added to his calendar.  It’s only a matter of time before this is both client and server side so that duplex will be having conversations with itself to schedule our days, and that’s pretty wild.

Android P Beta:

Yes, I know we discussed android P in the last blog on Google I/O.  But you’ll have to bear with me because it’s happening again! As of this week the Android P beta is available on Pixel devices as well as 7 other flagship devices.  Android P brings all kinds of cool new features to the table.  A lot of these revolve around predicting what you the user are about to do.  There’s an adaptive battery that adjusts your screen’s brightness and what apps are running in an effort to both improve your experience and conserve precious battery power.

My personal favorite feature of P is Wi-Fi RTT.  Round Trip Time takes our current location services capabilities and amplifies them.  Essentially by triangulating between multiple Wi-fi access points nearby, a user’s position can be calculated within about a meter.  Just use your imagination for what applications this could come in handy for!  For more on Android P you can read our past posts or watch some Google I/O talks.

There’s lots more to take away from Google I/O, and honestly I’m cutting myself off here because otherwise I’d end up writing a paragraph or two about every session that I watched from the entire conference.  It’s a great year to be an android developer or even just own an android device.

What interested you the most from the conference?  Let us know in the comments below!

 

Google I/O Is In!

Share if the site was helpful

Google I/O Is In!

We’ve talked about Google I/O being on the horizon here before, but we can do that no longer.  It’s here! (Actually once it’s over we’ll probably immediately start writing about 2019’s event).

Yes, today marks the kickoff of Google’s 11th annual conference.  And as such the entire Android population has a lot of stuff to talk about.  Google I/O started off strong with its keynote mapping out some of the things to be discussed this year.  Here are some of the highlights of day one:

Artificial Intelligence:

As with most other places these days, AI was one of the most used buzzwords at day one.  It’s somewhat become an all encompassing term for any technological advancement that helps us.  Despite this, Google separates itself from the pack by bringing some pretty cool new features to the table.  Whether it’s self-writing emails or auto adjusting screen brightness to your preference, Google is working on slipping AI into every part of our days.

Actually it’s so much cooler than that.  In the video above at 3:10 you can watch the Google Assistant play as your personal secretary.  It makes a call to a local hair salon and books an appointment without the person on the other end ever realizing they’re talking to AI.  Scary cool.

Android P:

There’s been lots of hype about Android P in the past few months, and we got to see more today.  With it’s 3 key themes of Intelligence, Simplicity, and Digital wellbeing, Android P seeks to one up everything else already in your hand and provide a predictive, pleasant experience.  We’ve talked before about some of the new features coming with Android P, and today that list only gets longer.

Adaptive Battery is a feature aimed to conserving battery life by using (you guessed it) AI.  It studies your app usage patterns and then can dedicate more battery power to conserving the things that you will likely be using in the near future.  Along with this comes the Adaptive Brightness feature I mentioned above where your screen will auto-adjust given your preferences.

Not only does P look to alleviate your battery strain under the hood, but it uses its predictive analytics to bring apps you’re about to use to the forefront.  P is currently available on a select few devices (9 total), and if you’re interested in downloading it click here.  If you’re unsure what you’re doing and want support with flashing your phone, then check out our Smartphone Tech Course over at Phonlab.  Otherwise stay tuned and we’ll post a guide in the near future.

Augmented Reality:

As for the other big buzzword topic, Augmented Reality had some cool new features to display.  Maps have been souped up with the newest computer vision features to recognize where you’re looking in the real world and flash both directional arrows for guidance as well as information about local places.  If you’re walking down the street and a restaurant catches your eye, say goodbye to opening up yelp and searching for its reviews.

The camera has also become greatly enhanced with its new capability to recognize where things are in the real world in terms of depth perceptions.  Moving your phone around your room, office, or down the street you’re able to get live estimates of how far away things are.  This is sure to be crucial in a lot of coming apps.

There’s a lot more to come in this year’s Google I/O, and we’ll keep you updated here.  Is there anything in particular you want us to go more in depth on?  Comment below and we’ll give you all the info you could dream of!

 

 

 

 

en English