今日已更新 257 条资讯 | 累计 40702 条内容
关于我们

标签:#Mobile

找到 250 篇相关文章

开发者

Samsung’s Galaxy Z Fold 8 feels like the future

Is this the future of foldable phones? Samsung clearly thinks so. The company has given its new wide foldable the "Z Fold 8" name, positioning the phone not as a widescreen oddity, but as the new normal, the default design for foldables going forward. Rumor has it that Apple feels the same way, with a […]

2026-07-29 原文 →
AI 资讯

Building a Parking Puzzle in Unity: A Systems Breakdown of the Park Match Mechanic

Parking and matching puzzles look almost insultingly simple from the outside. A few cars, a cramped lot, tap or drag to move them out. But if you've actually tried to build one that feels tight — no janky collision resolution, no ambiguous "why didn't that move register" moments, no lag once the board gets crowded — you know there's a real systems design problem hiding underneath what looks like a weekend project. I recently went through the architecture of a parking/matching hybrid template built in Unity and wanted to break down the core systems the way I'd want them explained if I were reskinning or extending one myself. This isn't a marketing post — it's a walkthrough of the actual mechanics: how vehicle movement and collision resolution work, how the match/clear pipeline is structured, how level data is separated from movement logic so hundreds of levels don't require touching code, and how monetization hooks slot into natural break points without polluting gameplay scripts. If you want to see the finished product this breakdown is loosely based on, there's a working template here: Park Match Unity Game Template . Everything below applies whether you're building something similar from scratch or extending an existing base. Why Parking Puzzles Are Harder Than They Look The core loop — tap or drag a vehicle, it exits along a valid path, the lot clears one piece at a time — is trivial to describe and genuinely fiddly to implement well. Four problems show up almost immediately once you move past a static mockup: Valid-move detection : how do you know, at any given moment, which vehicles can actually move given their orientation and the current board state? Path resolution : once a vehicle starts moving, how does it navigate around other vehicles and obstacles without clipping through them or getting stuck mid-animation? Match/clear logic : when does a vehicle actually "clear" the board — on reaching an exit, on matching color/type with another vehicle, or both — an

2026-07-29 原文 →
AI 资讯

Amazon’s trying to launch a global satellite cellphone network in 2028

Amazon filed an FCC application on Saturday to launch a new Leo satellite constellation that will provide direct-to-device satellite service for "voice, messaging, data, and emergency services." If approved, Amazon will begin deploying the new constellation of 5,105 satellites in 2028. It says it plans to partner with mobile network operators to offer direct-to-device satellite […]

2026-07-27 原文 →
AI 资讯

Accessibility Semantics: The UI Tree You Cannot See

Accessibility has become personal for me. I am getting older, and large type is no longer an abstract preference somebody else needs. It is how I read a phone comfortably. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . I worked with accessibility experts at Sun Microsystems and learned how deep the problem goes. A label is the easy part. Real accessibility needs roles, values, ranges, actions, traversal order, live announcements, collections, focus, platform conventions, and a way to test all of it. That complexity is why full Codename One accessibility support sat dormant for a decade. We eventually added setAccessibilityText() . It was useful, but it was the poor man's version. PR #5363 replaces that single-label model with a portable semantics tree we can be proud of. Lightweight UI needs a second tree Codename One paints lightweight components into its own native surface. VoiceOver cannot inspect a Button as a UIKit button because there is no UIKit button there. TalkBack cannot walk an Android View hierarchy because most of the painted controls are not Android views. The new accessibility manager builds an immutable virtual tree beside the visual component tree. Standard controls infer their semantics. Custom controls can replace or extend them. Each port exposes that virtual tree through the platform accessibility API. The visual and semantic hierarchies can differ. A card made from five labels might need to read as one item. A chart may paint 200 points from one component, but expose each meaningful point as a virtual child. A renderer-backed list can expose stable rows even though those rows are not component instances. Standard components work without annotations Buttons, checkboxes, radio buttons, sliders, text fields, lists, tables, tabs, labels, dialogs, and containers infer their normal roles, values, states, and

2026-07-27 原文 →
AI 资讯

Six months of running a GBA emulator

I shipped GoGBA (Android + iOS) to both stores in late December 2025. Six months in: MAU peaked at 8.3k, currently steady around 7.4k. No paid advertising, ever. This is a write-up of what the six months actually involved. I'll be specific about the technical work, and equally specific about the mistake that cost me RetroAchievements hardcore certification — because that part is the most useful thing here for anyone building in this space. Why GBA only I grew up on a GBA — Super Robot Wars, Fire Emblem, Pokémon, Castlevania, Zelda. Later NDS/3DS/PSP/Vita/Switch arrived and the GBA did its job and retired. On PC the emulator I remember is VisualBoyAdvance. I've used GBA, NDS and PSP emulators on phones. I kept coming back to GBA, for four reasons that are all practical rather than nostalgic: Pixel art holds up. Personal taste, no defense offered. Battery. A GBA game survives a long-haul flight. Single screen. The remaining screen space is exactly where virtual buttons want to go. NDS dual-screen on a phone is always a compromise. ROM hacks. The GBA hack scene is the richest of any handheld. Point 3 is the one that made me build something: GBA is the only handheld whose form factor natively fits a phone. That's a product observation, not sentiment. What existing emulators get wrong (for me) I used the main ones on both platforms: Delta and Linkboy on iOS; Pizzaboy, Linkboy and Lemuroid on Android. Lemuroid is open source and a lot of shipped emulators are built on it. They're all good. Every one of them had small things that annoyed me. The only genuinely cross-platform one is Linkboy (formerly MyBoy), but its configuration surface is extremely deep — second only to RetroArch in complexity. That's the gap. Everyone was solving "can it run" and "can it be tuned perfectly." Nobody was solving "pick it up and play." The methodology was just dogfooding I'm a Flutter GDE and tech lead for a 40-person cross-platform team; GoGBA was a solo test of that experience. The only r

2026-07-27 原文 →
AI 资讯

Widgets, Live Activities, and Dynamic Island From One Java API

Widget support was one of the earliest Codename One requests. We dismissed it for years because a widget must render while the application UI is not running. A normal Codename One Component needs the application renderer, event dispatch thread, and live object graph. A home-screen widget gets none of those. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . The missing piece had been under our nose for a decade. Steve added background processes so an app could refresh data without showing its UI. That solves the update side. The rendering side becomes possible once the widget is data rather than a live component. PR #5365 turns that observation into com.codename1.surfaces , one API for home-screen widgets, Live Activities, Dynamic Island, Android ongoing notifications, and desktop floating widgets. The dead-process rule An external surface is a piece of application state that the operating system can render outside the app. The app publishes a serializable layout and a timeline of state maps. The platform persists that data, then renders it with its own surface technology. You cannot attach a Java listener to a widget. There may be no Java process to invoke. You assign a string action ID instead. A tap launches the app and delivers that action after startup. The simulator implements the same model. Open Widgets > Widgets Preview to inspect every registered kind, move through its timeline, change size and appearance, and click actions without creating a device build. Widget kinds exist at build time iOS and Android compile widget galleries into the native application. The kinds must therefore be known during the build. Add a surfaces.json resource: { "liveActivities" : true , "kinds" : [ { "id" : "delivery_status" , "name" : "Delivery" , "description" : "Track your order" , "iosFamilies" : [ "systemSmall" , "systemMedium" ] } ] }

2026-07-26 原文 →
AI 资讯

Codename One Settings Is Now a Standalone Tool

Codename One Settings used to be a screen inside the old GUI Builder jar. It edited project properties, managed accounts, opened signing workflows, monitored builds, installed extensions, and accumulated every job that did not have a better home. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . PR #5359 replaces it with a standalone Codename One desktop application. It does fewer things, which is the point. One command, one project Run the new tool from a Codename One Maven project: mvn cn1:settings The Maven plugin resolves the com.codenameone:codenameone-settings artifact, launches it against the current project, and writes changes back to that project's codenameone_settings.properties and Maven configuration. The tool has its own release lifecycle instead of borrowing the GUI Builder's jar and version. This is the new Basic screen. It keeps the properties that belong to the source project: display name, package name, version, main class, icon, and related build choices. Build hints are searchable project data Build hints used to feel like an untyped text file with a dialog in front of it. The new editor preserves direct key-value control, but adds descriptions, known value types, filtering, and a focused editing flow. Nothing prevents you from editing the property file by hand. The Settings tool is useful when you do not remember whether the current spelling is ios.themeMode , and.themeMode , or a platform-specific signing key. It also keeps project values visible without mixing them with account state from the cloud. For example, selecting the modern native themes still produces ordinary project settings: nativeTheme = modern ios.themeMode = modern and.themeMode = modern The file remains the source of truth. The UI is an editor, not a second configuration system. Extensions keep compatibility warnings The Extensions screen

2026-07-26 原文 →
AI 资讯

Qualcomm is about to raise prices and that’s bad news for everyone

Qualcomm sent a letter to customers on Friday warning of plans to increase its prices by "a percentage in the double digits," Bloomberg reports. The price hikes will go into effect starting with products shipped after September 1st. Qualcomm claims it has "exhausted its ability to absorb higher costs from suppliers," as ongoing component shortages […]

2026-07-25 原文 →
AI 资讯

Nothing confirms layoffs, but calls market exit rumors ‘fake news’

In response to a report that Nothing is planning to "exit 12 markets as global shipments decline," Nothing cofounder Akis Evangelidis said the company is "reorganizing" and laying off some of its staff, but that "the reported numbers are way overblown." Evangelidis disputed a claim about underwhelming sales for Nothing's Phone 4B, saying it "sold […]

2026-07-25 原文 →
AI 资讯

Own Your Pixels: Native Fidelity on Your Schedule

An iOS or Android update can change a screen you shipped without you changing a line of code. If your app builds its UI from UIKit, SwiftUI, Compose, or Material widgets, Apple or Google owns those widget implementations. Codename One does something different. It statically links our lightweight component implementation into your native app. The UI you test is the UI your users keep after the next OS update. An update can still break a platform API or permission contract, but it cannot swap our button implementation for a new one. What is Codename One? Codename One is an open-source framework for building native iOS, Android, desktop, and web apps from a single Java or Kotlin codebase. Learn more at codenameone.com . Lightweight does not mean a Java paint loop limping behind the platform. On iOS, components paint through our Metal pipeline. The moving Liquid Glass tab lens in this post is a Metal shader on the frame's existing command buffer, with no transfer of pixels back to the CPU. At the same time, last week's ParparVM work brought our ahead-of-time VM to geomean parity with warmed Java 25 across ten benchmarks. Six finished at or ahead of HotSpot. The tradeoff is that our UI does not inherit Apple's or Google's latest redesign for free. We have to study it, reproduce the parts that make sense, and test the result. That is work we take on so you can work on your app instead of working for the Apple and Google design teams. You decide when your app adopts a new look. The OS does not decide for you on upgrade day. The ParparVM and theme-fidelity branches ran in parallel. We wanted them in the same release, but each became too large to merge together safely. The fidelity work took longer. PR #5274 alone reports 53,000 additions across 1,147 changed files. Generated access registries, resources, screenshots, and native goldens account for much of that number, but the scale is still real. Five follow-up PRs fixed what the first pass exposed. Owning the component sta

2026-07-24 原文 →
AI 资讯

The prompt didn't replace drag & drop

In GoodBarber, you build an app without writing code: you assemble components, drag and drop, with a design system holding everything coherent underneath. Recently, a second way in appeared: you can get a custom section by describing it to an AI in plain language. Two ways of creating now live in the same back office — and the question comes immediately: is this the beginning of the end for drag & drop? No. And that "no" isn't a defensive reflex — it's an interface-architecture choice you can reason about. The ladder everyone knows The history of creation tools gets told the same way by everyone, and it's true: a ladder of abstraction. First, code — total control, total complexity. Then direct manipulation — drag & drop: you touch the rendering itself, the first great democratization. Then components — you stop aligning pixels and start assembling coherent elements, governed by a design system. And now the prompt — you describe, the machine produces. Each rung up, you move away from the mechanics and closer to the intent. None of that is a revelation. What gets told less often is the conclusion you reach when you actually operate a product sitting on that ladder: every time a new rung appeared, the prediction was the same — this one makes the others obsolete. It never came true. The prompt won't be the exception, and here's why. What drag & drop does better — and always will For anything that can be shown, direct manipulation is unbeatable. This button, two pixels lower; this image, at the top of the section; this menu, in this order: the gesture is the description — the sentence explaining it to an AI is longer than the action itself. And a visual interface does something besides taking orders: it shows you what's possible. A settings panel is a map of what the product can do; an empty prompt field is an invitation to guess. That's why the no-code core of the platform — component management, screens, navigation, design — stays drag & drop, deliberately. It isn't th

2026-07-24 原文 →
AI 资讯

Mono-Repo + Multi-Repo: How We Structured 6 Apps Across 4 Repositories

Most teams treat "monorepo vs multi-repo" as a binary choice. Pick one, commit, move on. We ended up with a hybrid, and it turned out to be the right call — not out of indecision, but because our apps have genuinely different deployment and ownership characteristics. Here's what we built, why, and what it costs. The System The platform consists of six applications: App Type Primary Users REST API backend Node.js + TypeScript — (consumed by all apps) Society dashboard React web app Society managers, admins, accountants Company admin panel React web app Internal operations Marketing website Next.js Public Resident mobile app React Native (Expo) Residents Guard mobile app React Native (Expo) Security personnel All six apps talk to the same API. But they have very different deployment cycles, team ownership, and testing requirements. The Structure: 4 Repositories repo: main-platform (monorepo) ├── api/ — Express + Prisma backend ├── web-society/ — Society dashboard ├── web-admin/ — Company admin panel └── web-marketing/ — Marketing site repo: mobile-resident — Resident app (React Native) repo: mobile-guard — Guard app (React Native) repo: mobile-staff — Society staff mobile app (React Native) The web apps and the API live together in one monorepo. The three mobile apps each have their own repository. Why Split Mobile From Web? The driving factor was deployment cadence and review process . Web apps deploy on push — merge to main, CI builds, CDN updated within minutes. The feedback loop is fast, rollbacks are instant, and there's no approval gate between code and production. Mobile apps go through app store review. A release cycle includes building a release APK, submitting to Google Play (and Apple App Store), waiting for review, and then a staged rollout. The cadence is measured in days, not minutes. Mistakes are expensive to reverse — a bad release means submitting a patch, waiting again, and potentially having a broken version live for days. Given that difference, mob

2026-07-24 原文 →
AI 资讯

I Built a Manga Reader That Works on Every Platform --Here's How

I Built a Manga Reader That Works on Every Platform — Here's How Nyora is a free, open-source manga/manhwa/manhua reader for Android, iOS, macOS, Windows, Linux, Web, and even Docker — with AI-powered on-device translation and cross-platform sync. The Problem Every manga reader makes you choose: Free but ad-riddled (most Android readers) Polished but paywalled (commercial apps) Powerful but single-platform (Tachiyomi, Aidoku) I wanted one library — same titles, same progress, same bookmarks — on my phone, laptop, and browser. No ads. No account required. So I built it. What Nyora Does Every Platform, One App Platform Distribution Android APK (sideload) iOS/iPadOS IPA via AltStore/SideStore macOS .dmg or brew install --cask nyora Windows .exe (x64 + ARM64) Linux .deb , .rpm , or curl installer Web web.nyora.xyz — zero install Docker Single container, self-hosted No account needed to read. Cloud sync is opt-in. AI Translation That Understands Manga This is the flagship feature. Instead of dumping translated text over the artwork: Detects text baked into speech bubbles and captions Translates using on-device ML Typesets the result back over the original artwork Each platform uses the best local engine: Android : Google ML Kit + ONNX Runtime iOS : Apple Intelligence + Google Translate macOS : Apple Vision + MangaOCR CoreML Windows : Windows OCR Linux : Tesseract There's also an Ensemble AI Narrative Engine that tracks character names and speaking styles across chapters so translations stay consistent. 1,100+ Sources The Android app pulls from 1,100+ manga sources via 35 generic engine templates (Madara, FoolSlide, MMRCMS, etc.). Web has ~390 live, health-checked sources. Desktop ports are growing toward parity. Free Cloud Sync Sync library, categories, reading history, bookmarks, and exact page progress across all six platforms. Two sign-in methods: Google OAuth Nyora Cloud (email + password, free) Self-hostable — the backend is just Supabase/PostgreSQL with row-level s

2026-07-24 原文 →
AI 资讯

Samsung Galaxy Unpacked 2026: The 6 biggest announcements

Samsung's annual summer event kicked off on Wednesday morning with the company unveiling a new lineup of watches and foldables. Following weeks of rumors and leaks, Samsung announced the Galaxy Z Fold 8 with a completely new design that's shorter and wider than last year's Fold, a new "Ultra" Fold, an updated Flip model, and […]

2026-07-22 原文 →
开发者

I almost forgot Samsung’s Z Flip 8 was a foldable

Samsung's new Galaxy Z Flip 8 feels more like a regular phone than ever. It's thinner, lighter, and has a front screen you can do just about anything on. Whether that's a good or bad thing, I'm not quite sure yet. I spent three hours with Samsung's newest flip phone last week, and it doesn't […]

2026-07-22 原文 →
AI 资讯

Samsung’s wider Z Fold 8 feels just right

A year after overhauling its Z Fold phone with a radically thinner design, Samsung has changed things up again, this time altering the shape entirely. The Z Fold 8 is wider than any of Samsung's previous foldables, and shorter too, a size and shape somewhere between Samsung's traditional Flip and Fold models. In photos, I […]

2026-07-22 原文 →