Tag Archives: Android

SMS texts not coming to your Mac? Mac sure you’re signed into the same Apple ID for both Messages and FaceTime on your iPhone. (Seriously.)

The subject line is the answer, but here’s the longer story.

I recently switched iPhones. Through a series of stupid errors, I ended up having to set it up as a totally new phone instead of transferring my old phone data over.

Ever since I did that, some conversations refused to sync between Messages on my iPhone and Messages on my Mac, even though they were both set up properly and various online tutorials didn’t help me solve the problem.

That last tutorial hung me up on one particular detail though. The Text Message Forwarding option was not appearing for me in the Messages settings on my iPhone.

I figured this was just, once again, an outdated tutorial that hadn’t caught up to changes Apple had made in the Settings app. But… those screenshots looked current. Hmm.

I don’t even remember exactly how I made this mental leap, but I found the solution not in anything to do with Messages, but rather with the FaceTime settings.

Due to the long and complicated history of Apple’s online services, I have two separate Apple IDs. One I use for App Store purchases, and a different one I use for iCloud.

Well… on both the Mac and the iPhone I had Messages logged into my iCloud account. But on my iPhone, I had FaceTime logged into my App Store account. And that’s why the Settings app wasn’t showing me Text Message Forwarding in the Messages settings.

I logged out of my App Store account for FaceTime and logged into my iCloud account, and suddenly the Text Message Forwarding option appeared under Messages. I turned on forwarding to my Mac and my iPad, and now everything is working!

How to transfer files over 4 GB from Android to a Mac

I had to do some fairly deep digging to get this answer, so maybe I can help someone else.

I’m an Apple guy. But lately I’ve been having to record some video with a phone on a tripod, unattended. I don’t want to risk getting my iPhone stolen, so I’ve been using my Android testing phone instead (a Google Pixel 3a). It actually shoots pretty decent video, but getting that video off the Pixel and onto my Mac has been… a challenge.

After some initial digging the first time around, I discovered Android File Transfer. It’s a Mac app that lets you access the Android file system and transfer files over a USB connection. It’s just hard to remember exactly how to get it to work, at least for someone like me who is not super familiar with Android. The short version is you have to go into the Android device’s USB settings and turn on File Transfer mode.

Today I had a new problem. Once I got connected, I started to transfer two very large video files (16 GB and 9 GB) over to my Mac. All seemed to be going well, until I hit exactly 4.00 GB in the transfer, then it just stalled. No warning, no error. It just stopped transferring. Trying to cancel the transfer also didn’t work.

It’s really stupid that the app doesn’t just tell you this up front — or, like, you know, ever — but after digging into the issue, I learned the app has a 4 GB file size limit. I didn’t investigate why, but having dealt with this kind of nonsense on the Windows FAT file system in the past, I suspect it’s a stupid legacy quirk no one has ever considered important enough to fix.

Anyway, I needed another solution, and I found it. FTP. Specifically, I chose to use the WiFi FTP Server app. I mean really, you could use an FTP client app to transfer files to an FTP server, or install an FTP server on your Mac, but it just seemed easier to me to make the Android phone the FTP server, and let my Mac connect to it with Panic’s trusty (well… it used to be trusty, but that’s another blog post) FTP client, Transmit.

The FTP transfer is over WiFi, as the name implies, so yes, it’s slower than the wired USB connection. But… and here’s the key thing… it works.

P.S. After several minutes of the transfer running, I glanced down and noticed that the WiFi FTP Server app (which, of course, like most Android apps, is free to download) has an ad bar at the bottom. I hate to break it to those advertisers, but they are not getting any kind of R.O.I.

The mysteries of Google Photos and what my videos are teaching its AI

For the past few years I’ve been shooting video, sometimes very long video, on my iPhone, and then transferring it to my Mac for editing.

I have two ways to get the videos to my Mac. I can use AirDrop for a direct device-to-device transfer. But the videos also automatically upload to iCloud in the background, so I can then open the Photos app on my Mac and find them there, and download them from “the cloud.”

Neither way is exceptionally fast, especially with large files, simply because they are large files, but they both have always worked seamlessly, and I can pretty much do them on-demand as soon as the videos are done recording.

Last night I recorded a performance of the big band I play in, using… gasp! …an Android phone. Specifically, a Google Pixel 3a. Yeah, it’s pretty old. But also new to me. I need an Android phone for testing my web development work, but since I don’t use it as my day-to-day phone, I didn’t want to spend a lot. I know the Pixel is a good phone, with a clean Android install, and the price was right ($150). Which is exactly why it’s the phone I chose to shoot the video with, because I was going to have to leave it unattended all night in a crowded auditorium, about 100 feet away from me. It was unlikely to be taken, but I didn’t want to risk it with my main iPhone or even a backup. (Plus, the Pixel actually does shoot pretty good video.)

Anyway… once I got home, I then had to contend with the problem I knew would be waiting for me. This is an Android phone, so there’s no iCloud. But I am also pretty heavily invested in the Google ecosystem, so I figured I’d have no issues transferring the videos to my Google Drive — or at least Google Photos — and get them that way.

There are issues.

First, I can’t find a way to just put them on my Google Drive, which is where I really wanted them. Yes, I can just jump over to photos.google.com instead of drive.google.com, without even having to log back in, but I operate frequently in Google Drive and I had never, before owning this phone, had any reason to even consider the existence of Google Photos. But, whatever.

Second, and I could be wrong about this, it seems like the files only transfer from the device to the cloud when you have the Photos app open on the phone. I have the phone running on my home wifi, which is connected to gigabit fiber, so the transfer should be about as fast as can be expected anywhere in the United States, but even though I left the app open for an extended period last night, it only uploaded one of the two videos. I gave up waiting on it and went to bed, and uploaded the second one this morning.

But here’s the real kicker: neither of the videos is “ready” yet in Google Photos, not even the one I uploaded last night. Maybe it hadn’t quite finished uploading then but still… what exactly is Google doing to get the videos “ready”? Why aren’t they “ready” the instant they’re uploaded?

I get that videos uploaded to YouTube need to go through some processing. YouTube does all kinds of crazy crap to videos. Some of it is transcoding and optimizing the files for streaming, which… yes. 100%. Please do that. Some of it is machine learning (a.k.a. “AI”) driven, analyzing the content to make smart chapters and such, as well as detecting content that is illegal or violates terms of use. I see the benefits. And some of it is for the benefit of corporate overlords, both at Alphabet and elsewhere, such as detecting copyrighted music. Well… honestly there are pros and cons to that. But it’s not the point of this post.

The point is, I get why that kind of processing is happening to YouTube videos. But none of it should be happening to private videos uploaded to your Google Photos account. I suppose I should give Google the benefit of the doubt and assume that it’s strictly doing the AI scans for illegal content. (I think you know the illegal content I am talking about so I am not going to spell it out.)

Apple’s recent efforts to implement technology to do on-device detection of that type of content recently got a lot of heat for its privacy implications — even though on-device scanning is far more private than in-the-cloud scanning. But Apple always takes the heat for things because it’s Apple, despite Google, Amazon and Facebook engaging in much more egregious versions of those things.

The thing about Google in particular is, they’re all about amassing TOTAL WORLD KNOWLEDGE. Not in an inherently nefarious way (although maybe there’s no way for that not to be inherently nefarious). But there are always nefarious implications in what they’re doing. So whatever is going on as I’m waiting for my videos to be “ready,” the one thing I know for sure is that Google’s AI is learning something from them.

Update: I realized after I posted this that maybe I should… uh… google it. Yes, Apple themselves have provided instructions on how to transfer photos and video from Android to Mac. I realized that I could maybe use this USB-C to USB-C cable I have sitting right here at my desk to make a file transfer!

A passable but imperfect solution for full-bleed background images on Android and iOS

I’m working on a site right now that has a fixed, full-bleed (i.e. background-size: cover) background image on the <body>. The content flows over it, mostly obscuring it completely, but the background is occasionally revealed in the spaces between content blocks. Some blocks have a semi-transparent background so you can see the fixed background as if through frosted glass.

Here’s the CSS:

body {
  background: rgb(255,255,255) url('../images/ui/body_bg.jpg') center center no-repeat fixed;
  background-size: cover;
}

It’s a cool effect, but it really, really does not want to play nicely on mobile. Various odd things happen on both Android and iOS, and they are completely different.

Quick side note: Yes, the background image is a JPEG. Normally I only use PNG or SVG images in UI elements, but I had good reason to use JPEG here: even though it’s only two colors (with some in-between colors due to antialiasing), the pattern in the background is incredibly complex, and a JPEG version of the file is about 1/5 the size of the PNG. And since it’s an illustration, I tried making an SVG version first, but the pattern is so large that the SVG was about 2 MB! So JPEG it is… which may be a factor in the issue I’m having on Android, but I haven’t tested a PNG version of the image to verify that.

iOS Problems

I’m an iPhone user, so I mainly test responsive sites on iOS. I do own an Android phone (a Motorola Moto E, which I highly recommend as a cheap-but-decent Android phone for testing), but I generally only break it out during the final round of browser testing prior to launching a site.

The issues with background images on iOS are well-known to most web developers. iOS has a number of rather arbitrary seeming limitations imposed upon the Mobile Safari browsing experience, generally for one of three reasons: 1) performance, 2) touch interface usability, 3) the whims of the ghost of Steve Jobs. In the case of background images, background-attachment is not supported. I’m not really sure how this would impact either (1) or (2) — although I think with the early underpowered iPhone generations, it did impact performance — so I think we’re dealing mostly with (3) here. At any rate, because you can’t have an attached background on iOS, I added this in my media queries:

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;
  }

}

Another quick side note: Why is my phone break point at 782 pixels, you ask? Because that’s where WordPress has its break point for the admin interface. I’m not exactly sure why the WP team chose that number, but why fight it?

Besides the background attachment, there’s also the issue that background-size: cover on a phone is going to make the background image huuuuuuuuuge because it’s scaling it to fit the height of the page content, not the screen size. I initially solved that with background-size: 100%;, since we’re now allowing the background to repeat. As you’ll see, however, that led to problems on Android, so I ended up scrapping it.

Android Problems

Yes, Android has problems. Don’t even get me started! But I wasn’t prepared for this.

I opened the page in Android, and, although the background image was displaying as I expected in terms of size and attachment, it looked… awful. The original source image I am working with is a generous 2400 x 1857 pixels, enough to look reasonably sharp on most displays, even at high resolution. And it looks great on my Mac, great on my iPhone. But on the Android phone it was splotchy and low-res looking… like it had been reduced to 200 pixels and then upscaled (which is maybe what Android is doing, somehow… and here is where I’m wondering if the image being a JPEG is a factor, but that’s just a stab in the dark).

I tried a number of possible solutions, the most obvious being to set exact pixel dimensions for the image. I tried 1200 x 929, basically a “x2” size for high-res devices. Still looked like crap. I even tried setting it to 2400 x 1857, the actual dimensions of the image, and it looked like crap… and I don’t mean pixel-doubled, which is what it actually should be; I mean the same splotchy weirdness I had been seeing at other sizes.

And then I discovered David Chua’s solution:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;
}

Yet another quick side note: Here I am not placing this inside a media query. We don’t want to only fix this issue on phone screens. Granted, the iOS solution above needs to work on iPads, too… something I haven’t really solved here. I’m workin’ on it!

This change for Android worked perfectly! By this point I had, temporarily at least, removed the iOS workarounds I mentioned above, so on Android the background image was not only perfectly scaled to the browser window, looking sharp and clean, but it was even fixed-position, just like on desktop!

But… the image was back to being huuuuuuuuuge on iOS. Apparently this html trick for Android does absolutely nothing on iOS, so you’re left trying to find another solution that won’t simultaneously break Android.

An uneasy compromise

It’s not perfect, but I found that if I put both of these tricks together, everything works… the only thing we lose is the fixed-position treatment that Android allows but iOS does not. But the background looks great on both platforms and most importantly, behaves consistently on both.

Here’s the complete code I’m rolling with, for now:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;
}

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;
  }

}

As noted above, this doesn’t really address iPads. A simple solution would be to change the media query to @media screen and (max-width: 1024px), but a) that doesn’t account for the larger iPad Pro and b) it also means a desktop display will lose the proper background effect if the window is smaller than that size. I don’t really have a solution; an adaptive treatment using either server-side or JavaScript-based browser detection would be a consideration, but I don’t really like resorting to that sort of thing for something as basic as this.

It doesn’t help that I recently gave my iPad to my daughter so I don’t currently have a tablet of any kind for testing. That’s about to change as I have a newly ordered Kindle Fire arriving today, but of course that’s not going to give me the answer for an iPad. I can try Responsive Design Mode in desktop Safari, but that’s not always a perfect representation of the quirks of an actual mobile device.

Still… this combined solution for phones is an improvement over the default behavior in both cases.

The Outside Scoop: Thoughts on Android Wear and a possible iWatch

The big news in tech today is Google’s announcement of Android Wear, a version of their Android OS specifically optimized for “wearables” like watches.

The tech media is erupting with ridiculously titled blog posts that refer to this as Google’s “answer” to the iWatch, a product that Apple has not announced, nor even acknowledged working on.

Surprisingly, for the first time I actually found one of these wearables mildly interesting, the Moto 360. But I am still skeptical of wearables in general, smart watches in particular, and especially the idea that Apple is working on one. But I’ve learned from my past mistakes, when I was convinced Apple was neither working on a smartphone in late 2006 nor a tablet in late 2009. So, in my world at least, my adamant belief that Apple is not developing a watch should probably be my biggest clue that they are.

So where is Apple’s “iWatch”? Aren’t all of these competitors eating Apple’s lunch (before it’s even cooked)? Perhaps. But consider this:

Remember the original iPod. It came into a market that already existed (but sucked), and delivered a radically superior user experience, and was a huge hit. Remember the iPhone. Once again, it came into a market that already existed (but sucked) and totally revolutionized it.

The thing is… a smart watch market doesn’t really exist (or didn’t when rumors of an “iWatch” first started to circulate). It almost seems like Apple got the wheels of the rumor mill turning deliberately, to goad their competition into creating the market, thinking they were beating Apple to the punch but in fact creating the exact environment of suck Apple needs to release a product into.