Mobile App

#1

Finally got the client support to the point where the text chat works reliably:

photo_2022-06-29_17-05-21
photo_2022-06-29_17-05-21682×1280 91.4 KB

I was doing some brainstorming on how this should work and to me it seems the most important parts are quick switching between entry modes (say/pose/command) as it’s a bit annoying to type :s and "s even on smart keyboards, and the general utilization of the backlogs more (e.g. exits should output the available exits straight into the log as it’s simpler to scroll that than go modal into the room description overlay.

Any kind of ideas as to how the app should be laid out are generally appreciated; the last time I had to work with anything like this was zMUD (good god, the automapper). Overall I feel like the users activity (coming, going, looking at you) should all be in the chat log; the room info and character info should be inlined too. Character switching should be multi-finger swipes to preserve the screen estate.

For now I’m focusing on iOS/Android but it seems to work on windows and macOS with no major issues.

1 Like
Logging in with another MUCK client?
#2

Wow! :astonished:

You seriously got it to work that far? I am impressed!! :smiley:
Nice work, @farcaller!

#3

Woah, cool, you even got one of my patented o.O moments.

1 Like
#4

What technologies are you using? I’d love to help out with development and UX where I can.

#5

It’s all flutter and dart. Not exactly the most pleasant thing to work with but it does the job (and doesn’t look too ugly on iOS) and is properly cross-platform.

#6

Some extensive dogfooding over the weekend. A bunch of annoying observations.

When the mobile app goes asleep that pretty much stops the tcp traffic. You can deal with that on android, but there are no viable options on iOS. That effectively means that when you return to the app chances are the server already closed the connection but the client doesn’t know about it (yet); thus sending a message works but it disappears in the networking void. I’ve been adviced it’s a very annoying behavior.

There’s not much that can be done client side to improve the experience, unfortunately. The app goes stale, the server puts the character to sleep. I think we can only improve the user experience with some server side changes (@Accipiter, wanna have more headache? :smiley:).

What I roughly thought of is:

  • the mobile app registers with the server for push notifications.
  • the server will duplicate every event sent out by the wire with a push notification to apple/google.
  • if the client disconnects the ws, the server will allow the character to linger for more.
  • the client will try to reestablish the ws connection on every notification received, and, if it succeeds, the server must reset the lingering timer (but can leave the character idling).
#7

I believe I’ve heard this before, that there’s no real way to do persistent connections serverless on ios.

#8

There are¹.

  1. none of them is a valid reason for this app so it won’t ever pass the appstore review.
#9

Yea this is an issue we thought was isolated to browsers and webviews, one of the reasons I wanted to make a native app. You obviously got to it first. :grin:

As for the appstore review, seeing as f-chat’s official app still isn’t on either major appstore, I would imagine one for mucklets wouldn’t get approved for the same reasons. Apple especially wants to remove adult themes from their ‘curated experience’, one of the reasons why reddit and discord need to have nsfw content enabled by another device

#10

Yup. I don’t think it’ll ever happen except for sideloading on ios. Can you even do that these days?

#11

The way f-chat does it is through an extended testflight that they keep renewing.

#12

Hahaaa. That’s one of those things that’ll work until it doesn’t.

#13

Well I have no experience with flutter/dart, but would be more than willing to learn if you’d like some help. Most of my experience is in C# and Java, but good practices mean a lot more than syntax.

#14

f-list only supports f-list. My app actually has no relation to Wolfery, doesn’t contain the name Wolfery, and supports any mucklet server: the pure-spirited MLP mucks, candy-themed worlds, even the muck for the Mario fans. Of course, given the content isn’t moderated it will still have to be eared as 18+ but there won’t be any sexual content in the app. None at all.

#15

Sure, welcome on board. Flutter is extremely annoying in some places, godsend in others; I seem to have a love/hate relationship with it now. I’m still waiting for some issues to be sorted out before I can open-source it, but I’ll publish it ASAP.

#16

I mean, from the quick looks I’ve had it almost looks like what typescript could have been if it wasn’t bounded by javascript’s design decisions.

But don’t feel too rushed to open source it, I can start whenever :grin:

#17

cries in lack of union types

#18

I said C# and Java were my backgrounds :grin:

I’ve never used a union type in my life :slight_smile:

#19

I don’t have any experience developing for iOS, but I am very familiar with the headaches that it causes with hanging on to connections. The only IRC client I found that works on iOS is IRCCloud, because it’s really just acting as a bouncer.

I can confirm that there are MU* clients on the normal iOS app store, though. I believe I’ve used MUDRammer and Wyvern, though it’s been a long while and I couldn’t tell you which I settled on. f-list is probably running into issues because they’re explicitly geared toward sexual content in various forms.

#20

And yet, Telegram’s on the iOS app store, and there’s certainly adult content available over that, too. I was about to wonder if F-List is kept off the app store because adult content is their primary stated raison d’être (I seem to recall it started as a kink list and added chat later). That might be why it’s kept off entirely, whereas Reddit and Discord have to put up with shenanigans to enable it.