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

标签:#ui

找到 511 篇相关文章

开发者

DBNavigator – An DataGrip-inspired Database IDE Built with JavaFX

After months of development, I'm excited to share DBNavigator, a cross-platform database IDE that I've been building from scratch using Java and JavaFX. ✨ Current Features ✅ PostgreSQL support ✅ MySQL support ✅ Modern Datagrip-inspired UI ✅ Multi-tab SQL editor ✅ Syntax highlighting ✅ Schema explorer ✅ Query execution ✅ Professional dark theme ✅ Cross-platform (Windows, Linux & macOS) This project has been an incredible learning journey in desktop application development, JavaFX UI design, database connectivity, and IDE architecture. I'm sharing it with the developer community because I'd genuinely appreciate your honest feedback. I'd love to hear your thoughts on: UI/UX design Performance Missing features Overall developer experience Architecture and code quality Any bugs or improvements you notice Whether you're a Java developer, DBA, or someone who works with databases every day, your feedback would mean a lot and help shape the next version of the project. ⭐ If you find the project interesting, please consider giving it a star on GitHub. GitHub: DBNavigator Thank you for taking the time to review it. Every suggestion, issue report, and critique is greatly appreciated! 🙌

2026-08-08 原文 →
开源项目

Building Small Things

Recently, I’ve been spending more time building small projects on my own. One thing I’ve learned is that it’s usually better to keep things simple and ship early instead of trying to make everything perfect. A small project can still teach you a lot about coding, deployment, design, and how people actually use what you build. I’m planning to share some of my development notes and experiments here from time to time. Looking forward to learning from everyone on DEV.

2026-08-07 原文 →
AI 资讯

ESP32 HTTP Client Sem Dores de Cabeça: Consuma REST APIs com Zero Alocação de Memória

Consumindo REST APIs no ESP32 sem Estourar a Memória: Conheça o ESP32-HTTP-Client Se você já desenvolveu projetos IoT no ESP32 que se comunicam com APIs REST (seja para enviar dados de sensores para a nuvem, consultar status de serviços ou integrar com Firebase e AWS), provavelmente já enfrentou um destes problemas clássicos: Fragmentação e estouro de heap: O combo padrão HTTPClient + ArduinoJson precisa carregar todo o payload HTTP na RAM como String antes de desserializar o JSON. Em payloads médios ou grandes, isso gera Out of Memory ou travamentos intermitentes. Lentidão em requisições consecutivas: O HTTPClient padrão refaz o handshake TLS/TCP repetidamente, adicionando centenas de milissegundos a cada chamada. Código verboso e boilerplate excessivo: Mais de 15 a 20 linhas de código para instanciar clientes, extrair buffers, checar erros e navegar em nós JSON. Para resolver esses gargalos de forma elegante e moderna, foi criada a biblioteca ESP32-HTTP-Client . O que é o ESP32-HTTP-Client? O ESP32-HTTP-Client é um cliente HTTP/REST moderno, fluente e orientado a objetos para ESP32, projetado especificamente para sistemas embarcados de alta eficiência. Em vez de "fazer download da resposta, guardar na memória e depois processar", ele utiliza Direct Memory Binding (injeção direta) e Stream Parsing : os dados do JSON são lidos diretamente do stream da rede e injetados direto nas suas variáveis ou struct s em C++, sem armazenar o payload inteiro na RAM . // Uma linha. Zero strings intermediárias. Injeção direta em memória. client . get ( "/sensor" ). getBody ( "temperature" , & myFloatVariable ); Benchmark: ESP32-HTTP-Client vs Abordagem Tradicional Em testes controlados com 100 requisições HTTP consecutivas contendo payloads JSON (usando o endpoint /users do JSONPlaceholder), os resultados comprovam a economia de recursos: Métrica / Recurso HTTPClient + ArduinoJson (Padrão) ESP32-HTTP-Client Diferencial Heap alocado por requisição ~58.2 KB ~0.0 KB (15 bytes) ~99.9%

2026-08-07 原文 →
AI 资讯

Architectural Excellence in Modern Android: Jetpack Compose, MVVM, and Clean Code Principles

Introduction: Moving Beyond Traditional XML Layouts Android development has evolved significantly. The days of managing complex XML layouts with findViewById or basic View Binding are fading fast. Modern Android development demands clean architecture, reactive state management, and declarative UI tools like Jetpack Compose. In this deep dive, we will explore how to structure scalable, maintainable, and testable native Android applications using the Model-View-ViewModel (MVVM) architecture alongside Jetpack Compose. Why MVVM with Jetpack Compose? The Model-View-ViewModel pattern provides a clean separation of concerns between your business logic and presentation layer: Model: Handles data sources (Local database via Room, Remote API calls via Retrofit). ViewModel: Preserves state during configuration changes, holds business logic, and exposes state observables. View (Compose): Declarative UI composables that automatically re-compose (re-render) when the underlying state changes. Using Jetpack Compose alongside MVVM eliminates UI boilerplate code, avoids memory leaks associated with traditional views, and simplifies dynamic UI state management. Layered Architecture Overview The Data Layer The data layer is responsible for retrieving and storing data from external or local sources. It uses the Repository Pattern to expose a clean API to the rest of the app: Kotlin interface UserRepository { suspend fun getUserProfile(userId: String): Result } class UserRepositoryImpl( private val apiService: ApiService, private val userDao: UserDao ) : UserRepository { override suspend fun getUserProfile(userId: String): Result { // Handle network requests, local caching, and fallback strategies } } The Domain Layer (Optional for Large Apps) Contains Use Cases (Interactors) that encapsulate single pieces of business logic. This ensures that ViewModels remain lightweight and focused strictly on managing UI state. The UI Layer (ViewModel + Composables) The UI layer reads state exposed by

2026-08-06 原文 →
AI 资讯

Building a Reliable AI Image Pipeline: Tasks, Failures, and Credit Refunds

Most AI image generators look like a prompt box with a Generate button. That is also how my first version started. But once real users entered the workflow, the difficult problems appeared somewhere else: browser refreshes, external task IDs, reference images, partial failures, credit refunds, private assets, and public artwork moderation. While building Magggic , I learned that an AI image generator is less like a form submission and more like a small distributed job system. This article covers the decisions that made that workflow more reliable. The code samples below are intentionally simplified. The important part is the shape of the workflow, not a specific database or image provider. The prompt box is only the beginning A synchronous prototype is easy to imagine: const images = await provider . generate ( prompt ); return images ; That version works until the request takes a minute, the provider times out, one of four requested images fails, or the user refreshes the page. The production workflow I needed looked more like this: Prompt + references ↓ Create a local queued task ↓ Charge credits with an idempotency key ↓ Submit work to the image provider ↓ Persist every completed output immediately ↓ Finalize the task and refund failed outputs ↓ Keep the result private until the user publishes it The provider request is only one step. The local task is the source of truth for what the user sees. 1. Persist the task before calling the provider The first important decision was to create a generation record before making the external API request. A generation stores the information needed to reconstruct the job: type Generation = { id : string ; userId : string ; idempotencyKey : string ; prompt : string ; referenceImages : string []; model : string ; ratio : string ; resolution : string ; count : number ; cost : number ; status : " queued " | " generating " | " completed " | " failed " ; outputs : string []; providerRequestIds : string []; failureReason : string |

2026-08-06 原文 →
AI 资讯

I Built a Free Tool Site with 15+ Developer Tools — No Sign-up, No Ads, No Bullshit

Hey everyone! 👋 I'm a developer who got tired of visiting 10 different websites to do simple tasks like formatting JSON, compressing images, or generating QR codes. So I built DevToolBox — a single place with 15+ free online tools, all running in your browser with no sign-up required. 👉 https://toolbox-site.asia Why I Built This Every time I needed a quick tool, I'd end up on a site full of ads, popups, or "create an account to continue" walls. I wanted something clean, fast, and respectful of users' time and privacy. The idea was simple: one website, all the tools you need, zero friction. What's Inside Here are some of the tools available: Developer Tools: JSON Formatter & Validator — Format, validate, minify JSON with syntax highlighting Base64 Encoder/Decoder — Encode and decode Base64 strings instantly UUID Generator — Generate v4 UUIDs in bulk 🔧 Unix Timestamp Converter — Convert between timestamps and human-readable dates 🔧 Regex Tester — Test regular expressions with real-time matching 🔧 Markdown Preview — Write Markdown and see the output live Hash Generator — MD5, SHA-1, SHA-256, SHA-512 🔧 Diff Checker — Compare two texts side by side Daily Tools: 🖼️ Image Compressor — Compress images right in your browser Image Format Converter — Convert between PNG, JPG, WebP Password Generator — Create strong, customizable passwords 📱 QR Code Generator — Generate QR codes with custom colors BMI Calculator — Calculate Body Mass Index 🎂 Age Calculator — Calculate exact age from birth date 📝 Word Counter — Count words, characters, sentences 📏 Unit Converter — Length, weight, temperature, and more How It's Built The whole site is a Vue 3 + TypeScript + Vite project with Tailwind CSS for styling. Everything runs client-side — no data is ever sent to a server, which means your data stays on your device. Key tech: Vue 3 with Composition API TypeScript for type safety Vite for blazing fast dev experience Tailwind CSS for styling Vue Router with history mode for clean URLs vue-i1

2026-08-06 原文 →
AI 资讯

Understanding MVVM by Building a Simple Weather App with SwiftUI

MVVM with swiftUI When learning SwiftUI, one of the first architectural patterns you'll encounter is MVVM (Model-View-ViewModel). In this tutorial, we'll build a simple weather application that consumes the OpenWeather API while applying MVVM, dependency injection, and protocol-oriented programming. By the end, you'll understand not only how to structure the project, but also why each layer exists. This is the link for the OpenWeather API https://openweathermap.org/api . What you'll learn By the end of this tutorial you'll know how to: Structure a SwiftUI project using MVVM. Consume a REST API using async/await. Apply dependency injection using protocols. Display loading and error states. Keep Views focused only on UI. This is how the data flow looks. User taps "Search" │ ▼ ┌──────────────┐ │ ContentView │ └──────┬───────┘ │ await fetchWeather() │ ▼ ┌────────────────────┐ │ WeatherViewModel │ └─────────┬──────────┘ │ ▼ WeatherServiceProtocol │ ▼ ┌─────────────────┐ │ WeatherService │ └──────┬──────────┘ │ ▼ OpenWeather API Project Structure WeatherApp ├── Configuration │ └──AppConfig.swift ├── Models │ ├── Main.swift │ ├── Weather.swift │ └── WeatherResponse.swift ├── Services │ ├── WeatherService.swift │ └── WeatherServiceProtocol.swift ├── ViewModels │ └── WeatherViewModel.swift └── Views └── ContentView.swift Configuration contains application-wide constants such as the API key and base URLs. Models contains the data structures used to decode the API response. Services is responsible for networking and fetching data. ViewModels contains the presentation logic and exposes data to the UI. Views contains the SwiftUI interface. On the AppConfig file, we are going to keep static info, just like the base URL, API key, etc struct AppConfig { static let apiKey = "YOUR API KEY" static let baseGeoCodingAPIURL = "https://api.openweathermap.org/geo/1.0/direct?q=" static let baseURL = "https://api.openweathermap.org/data/2.5/weather?&units=metric&lat=" } Designing the UI Befo

2026-08-06 原文 →
开发者

Building for the Next Wave: My Journey Crafting Next.js Templates for the Nigerian Market

Bridging Design and Code to Empower Local Businesses As a full-stack developer specializing in JavaScript and React, one of the most exciting ventures I'm currently on is building ready-made websites and Next.js templates through Softchic. This isn't just about coding; it's about deeply understanding the needs of businesses, particularly within the vibrant and rapidly evolving Nigerian market, and translating those into high-performance, beautiful web solutions. Why Next.js? Performance, SEO, and Developer Experience My choice of Next.js as the primary framework for these templates was deliberate: Performance: Server-side rendering (SSR) and static site generation (SSG) capabilities are crucial. In areas where internet speeds might vary, a fast-loading website isn't just a nice-to-have; it's essential for user retention and conversion. SEO: For businesses looking to establish a strong online presence, robust SEO capabilities out-of-the-box mean our templates provide a solid foundation for discoverability. Developer Experience: Building with Next.js allows for efficient development, leveraging the power of React while simplifying routing, data fetching, and API routes. This means faster iteration and higher quality templates. The Nigerian Market: Unique Challenges, Immense Opportunity Crafting templates specifically for the Nigerian market presents a fascinating set of considerations: Design Aesthetics: Understanding local preferences in terms of color palettes, layouts, and user flows is critical. It's not just about what looks good globally, but what resonates locally. This is where my dual role as creative director for promotional materials comes into play – applying that eye for design directly to the templates. Mobile-First Mentality: A significant portion of internet users in Nigeria access the web via mobile devices. Every template is meticulously designed with a mobile-first approach to ensure optimal responsiveness and user experience on smaller screens. Aff

2026-08-06 原文 →